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Executive Summary 



Objectives 



MIMOSA aims at providing a framework for an information system dealing with the exchange 
and the management of medical images. It includes three aspects : 

• a conceptual model describing the nature of biomedical images, their role in diagnosis and 
therapy, their behavior and dynamics, and the operations involved in their handling. 

• state-of-the art technology assesment with respect to its ability to implement the above 
conceptual model. 

• implementation of the above model using the most appropriate technology, and technical 
assesment of the resulting information system. 



Approach 



The modelling activity, based on the NIAM method and supported by a specific CASE tool 
managing the consistancy of the model, followed the ISO information system modelling 
standards. Three inter-related models, the MIMOSA data model, the MIMOSA functional 
model and the MIMOSA dynamic model fully specify the medical image management system. 

Implementations of this model is crucial to provide useful feedback information and 
demonstrate MIMOSA ability to efficiently manage images and related informations in 
clinical situations. 



Results 



The MIMOSA model has been developed using a generic and modular approach : it provides a 
solid foundation for the design of an efficient image management system for various users and 
clinical sites through abstraction of common categories of functions (information access and 
selection, information availability, and communition between users) while adressing 
performance requirements specific to image management. 

The prototypes developped at RENNES, LUXEMBURG and PISA demonstrate most of these 
functionalities offered by a MIMOSA kernel to users : Information availability through 
prefetching, preloading and layered archive mechanisms (RENNES), communication between 
users (LUXEMBURG and PISA) and information access and selection through worklist 
management (RENNES). Userful feedback to the modelling activity was provided at imple- 
mentation time, reflecting adequation of theoritical approach inherent with modelling technics 
with concrete implementation. 
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The aim of the EurlPACS / MIMOSA project is to model medical image management. Even though people may not 
agree on the usefulness of modelling medical image management, it should be clear to everybody (users, as well as in 
industry) that, to a great extent, the PACS concept has not been as successful as expected ten years ago. The main 
reasons to explain this are associated with the extreme variety of users' expectations, the focus on technological 
aspects rather than on users' requirements, the lack of suitable standards and the gap between users' needs and the 
capabilities of prototype systems. 

A successful PACS implementation must be based on users' requirements. These must be expressed in a generic way, 
which means that they are based on a model which is widely accepted. Only then can cost effective and useful PACS 
implementation be created. The key issue is not: "should medical image management be modelled?". It must be 
whether: "is it possible to define a generic, widely accepted model for medical image management?". A negative 
answer to this latter question implies (the MIMOSA topic group believes) that PACS as a commercial product is not 
feasible in this very general sense. For those who believe in PACS, medical image management should be considered 
as an absolute necessity, as a first step in that direction without which no real progress in PACS can be made. This 
does not mean that PACS research should only focus on modelling, since it is also necessary to gain practical 
experience, for example using newly available technology, and in evaluating the clinical usefulness of PACS. 

7. 1. Why modelling is needed in medical 
imaging 

1. 1. 1. The main reasons for poor success of PACS 
projects 

For more than 10 years, numerous PACS projects have been initiated throughout the world but in many cases without 
satisfactory results. In particular: 

1. There are few commercial products available. 

2. Very few systems work as anticipated. Those few systems which are cited as working are usually poorly adapted 
to users' needs: they are slow, they require a lot of user interaction and, often, they are not connected to the local 
Hospital Information System (HIS). Often their scope is rather limited, for example to only one department, while 
image management as such is still based on film. 

Such a negative judgement on such PACS development does not mean that all such systems are therefore neither 
useful nor feasible. This poor performance is the result, typically, of too much effort which has been put on 
technological aspects (networking, high capacity storage devices, high quality displays), and not enough on essential 
aspects of medical imaging, viz. management. 

Three main reasons for the poor success of existing PACS are commonly suggested as being: 

1 . Since most people were perfectly happy with film based image management, PACS was not considered by the 
users as a necessity. 

2. The PACS concept is not well suited to users' needs since PACS fulfils marginal requirements while not 
providing essential ones. For example a PACS network is often considered as being an extension to image 
sources (the image acquisition devices), and purchased as a type of "imaging equipment", not as an information 
system. 

3. The PACS set-up was not implemented in the 'proper' way: 

-Implementing PACS is usually a complex task because experience shows that it requires gradual 
implementation during which the film-based approach and digital management must co-exist. 

- Implementation often does not take into account the existing organisation of any concerned departments and 

human factors such as training and modification of job profiles. 

- PACS implies a change in organisation which is not easily accepted. 
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- PACS development does not take into account economical factors. The added value provided by PACS has 
often been found to be marginal, and investments in new image sources are often preferred. 

Although the contractors developing the EurlPACS / MIMOSA topic understand such criticisms, they have a different 
viewpoint: 

1. PACS is potentially very useful. There is an abundant literature showing what can be done with PACS which 
cannot be done otherwise (avoiding loss of patient folders, speeding up image access, sharing of costly resources 
required by sophisticated image processing, etc.). 

2. PACS implementations should be well suited to users' needs. PACS capabilities and functions must be carefully 
specified with users tightly involved in this process. PACS functions cannot be decoupled from those required by 
the management of medical information seen as a whole. In other words, image data and associated information 
form just one subset of medical information in general, including clinical information and laboratory data. 
However it is likely that it will be necessary to use those means and methods appropriate for image data in order 
to achieve a successful implementation. 

3. The methodology used in designing, implementing and maintaining PACS must generate substantial added value 
or achieve productivity gains while reducing PACS investment and running costs. This implies that one must 
propose an approach general to medical image management but capable of being customised according to users' 
needs. 

In summary the basic viewpoint of EurlPACS / MIMOSA contractors is that PACS may be feasible, useful and cost- 
effective, given that an application and implementation independent model of medical image management can be 
defined and is acceptable to the medical imaging community. Following the ISO modelling standard, such a model 
must include three components: a data model, a functional model and a dynamic model. Since image information is 
considered as a subset of medical information, the resulting system must be able to communicate with other 
information systems, and therefore must be designed in compliance with open system architecture. 

1. 1.2. E vidence of modelling 

As pointed out by Saranummi et al. [1992]: "... a world-wide consensus of PACS should be possible. ... this consensus 
needs to be developed by convergence of three points of view: ... the user requirements for PACS and standardisation 
in PACS". As stated by them and many other authors, a necessary condition for PACS success is that PACS systems 
satisfy the user requirements. These requirements need to be described in terms of the points of view of users 
concerning performances, services, etc. However, these requirements are usually formulated using vague sentences 
incorporating much implicit knowledge since such users have their own language and their own base of culture and 
experience. To identify, classify, and abstract essential relationships, to organise information, and to gather the various 
users points of view, it is necessary to construct a formal structure from which the implemented system is derived 
[Bidgood et al. 1992]. This operation is the scope of the modelling process, whose fundamental role is widely 
accepted is the following terms. "A model is an abstraction of something for the purpose of understanding it before 
building it. Because a model omits non essential details, it is easier to manipulate than the original entity. Abstraction 
is a fundamental human capability that permits us to deal with the complexity. Engineers, artists, and craftsmen have 
built models for thousands of years to try out designs before executing them. Development of hardware and software 
systems is no exception. To build complex systems, the developer must abstract different views of the system, build 
models using precise notations, verify that the models satisfy the requirements of the system, and gradually add details 
to transform the models into an implementation." [Rumbaugh et al. 1991]. 

1. 1.3. Rationale of prototyping 

The use of CASE tools guarantee in the modelling process the syntactic consistency of the model, verifying the proper 
use of concepts, relationships between concepts, etc.. For instance, these tools require that every concept has an 
identifier. However, this adequacy of the model with the universe of the discourse is not ensured. 

The prototyping phase, based around the semantic consistency checking, implements (parts of) the model, integrating 
the needs assigned by end-users in terms of user interface. As the discussions about a conceptual model may be 
difficult, prototyping allow users and developers to discuss about a concrete model, understandable by both of them. 
Moreover, since relationships between the various analysis levels of a system (external, i.e. user oriented; conceptual 
and internal, i.e. implementation oriented) exist, a better understanding of the conceptual and internal levels may result 
from prototyping. 



-3- 



— Introduction — 



1.2. Main modelling objectives 



1.2. 1. Objectives and world to be modelled 

The complete MIMOSA topic aims at providing a framework for an information system dealing with the exchange and 
the management of medical images. It includes three aspects: 

1 . A conceptual model describing the nature of biomedical images, their role in diagnosis, therapy and teaching, 
their behaviour and dynamics, and the operations involved in their handling. 

2. An assessment of state-of-the-art technology with respect to its ability to implement the above conceptual model. 

3. Implementation of a demonstration of the above model using the technology judged to be the most appropriate, 
and evaluation of the resulting information system. 

1.2.1.1. MIMOSA scope 

MIMOSA aims at providing a conceptual framework of image management for a variety of users. It is claimed to be 
application and implementation independent, and comprehensive since it includes all facets of biomedical image 
handling, both computer and paper based. 

MIMOSA takes into account: 

1. Users manipulating biomedical images (who they are, what their technical or medical responsibilities are, what 
their intentions when acting on images are). 

2. Image handling scenarios associated with routine and research utilisation, in terms of goals and triggering events, 
from a user' s viewpoint. 

3. Biomedical image behaviour and dynamics in order to manage and supervise the changes and transformations 
they undergo. 

4. Data involved in biomedical image handling. 

The MIMOSA scope can thus be summarised as follows: the biomedical image 'actors' are image sources, image 
users, image archiving systems and HIS / RIS. The interfaces between such actors are of different nature, and more or 
less easy to define: 

1. The interface to the image source is fairly well defined, since most image sources are stand-alone systems, and 
since this interface has been the topic of extensive standardisation efforts such as DICOM and MEDICOM. 

2. The image user interface is more difficult to define, since image use may correspond to image processing, 
analysis, interpretation or viewing; the interface must provide users with information needed by the task 
undertaken while being application independent. 

3. The archiving system interface must allow various file format standards to be used for archiving and retrieval of 
image data to and from various image sources and image user environments. 

4. The HIS / RIS interface must be able to provide image related information to the HIS / RIS, and to retrieve 
HIS / RIS data used in image management. This is clearly the fuzziest interface since, for different 
implementation, images are likely to be managed using HIS / RIS systems having quite different functionality. 

1.2.1.2. Model building 

Model building is based on a two step process: 

1. A preliminary study to specify the scope and the context of the modelling task with three objectives: to provide 
general guidelines and references, to identify concepts and relationships relevant to the universe of interest, and 
to list external constraints. 

2. A second phase to deliver a complete, detailed and verified conceptual model of data, functionalities, and 
dynamics. The last part organises the functional relations into scenarios including considerations such as 
sequencing, time constraints and error handling, so as to organise conceptual data contents into data structures 
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and functions into service structures, and to check whether the resulting structures cover all organisational and 
system requirements. 

The first phase has been completed resulting in a document, the WP 2 report, which was published in March 93 (cf. 
Appendix 3). The second phase resulted in the data, functional and dynamic models as presented in the end 1993 
deliverable: "MIMOSA overall specifications - preliminary version). The criticisms resulting from the publication of 
this report were used to improve the models. 

1.2. 1.3. MIMOSA analysis methodology 

The tools used for modelling are briefly presented here, since details will be given in the corresponding sections of the 
report. 

The data model is based on using the NIAM information analysis method, the functional model on Data Flow 
Diagrams, and the dynamic model on Petri nets. The adequacy of the MIMOSA model in representing the real world is 
checked using qualitative reasoning, using clinical cases (scenarios). 

1.2.2. Basic assumptions 

For the functional model, it is assumed that certain basic functions for handling of biomedical images exist, which are 
application independent (e.g. independent of medical speciality and of locality). It is claimed that differences in image 
use are essentially induced by organisational differences, not by functional differences as claimed by some authors. 
The success of the MIMOSA model largely depends on obtaining the support of a large part of the medical imaging 
community such that they accept this assumption, which is one of the main reasons of carrying out this project under 
the auspices of the European Community. 

For the data model, it is assumed that medical imaging, despite its diversity, can be described by a rather limited set of 
concepts applicable to all imaging modalities and application fields. It has been experienced that the major difficulties 
seem to reside in terminology, since often the same words are used with different meanings, while different words are 
often used for the same concept, depending on location and application field. The proposed model is based on a 
dictionary on which the MIMOSA contractors and their contacts in various European institutions have agreed. 

1.2.3. Difficulties experienced 

1.2.3. 1. Definition of the universe of interest 

Since the MIMOSA model is intended to be application and implementation independent, while taking into account 
medical imaging users' viewpoint, two types of difficulties were encountered, being: 

1. Where to locate the border between image management and medical imaging applications? For instance does one 
have to model each possible image processing procedure (an example might be to model isodoses superimposed 
on images in radiotherapy)? Such choices are essentially related to the definition of the interface between 
MIMOSA and image users. The position adopted was to keep the MIMOSA model as general as possible, and to 
provide data structures and functions permitting applications to get appropriate and understandable information 
from MIMOSA, and to enter any resulting image information into it. 

2. Does one have to manage image information produced by image sources and image users, or can one manage 
how such information is produced as well? Such an issue has essentially to do with the interface between 
MIMOSA and the HIS / RIS. The stand-point adopted was that the MIMOSA model must also describe the data 
and the functions involved in image production. However this model must be implementation independent, i.e. 
the resulting data structures and services may exist in MIMOSA, HIS / RIS, or both, depending on 
implementation. It is not the objective of MIMOSA to define what kind of data a HIS / RIS should include in 
order to manage medical image information. 

If the position taken on these two issues is clear, it is not completely satisfactory since, while a user wants to interact 
with a fully integrated system, an information system designer wants to keep image information management separated 
from the management of other information types and from applications. This is one more reason to adopt an open 
system architecture, such that a user can perceive the interoperative information management system and application 
environment as a whole. 
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1.2.3.2. From the organisational level to the functional level 

In order to take into account users' needs, end-users must be asked about their functional requirements. It often 
appears that they are unable to express their functional requirements in formal terms, but rather tend to describe their 
own organisational system. If this information is used as such, the resulting model may be tuned to that specific 
organisation, and will have lost its generality and will reproduce the limitations of that organisation. It is therefore 
necessary to extract the functionalities buried in the organisational description, and to evaluate to which extent they are 
generic and organisation independent. 

Translating organisational oriented interviews into generic functionalities turned out to be a difficult task, which could 
be achieved only because a large and diverse panel of European users expressing very different viewpoints was 
available, and because our modelling group had extensive experience of medical imaging. 

1.2.3.3. Staying independent of implementation considerations 

Because most experts have been involved in digital image processing and management, their interviews are strongly 
'polluted' with implementation considerations. For example many users think in terms of disk access time rather than 
in terms of data availability. Such subtle implementation considerations bend the data and functional models toward 
particular organisational and implementation schemes, which must be avoided. 



1.3. Related works on modelling 

The modelling approach described in section 1 .2 is used by the MIMOSA topic. In order to compare the approach of 
others with that of MIMOSA, although there are not many published papers about modelling in the field of the PACS 
concepts and projects, the following sections present a short survey of the work of others in specifying PACS using a 
modelling process. Some such models deal with performance, architecture, cost or acceptance issues. However, few 
are concerned with conceptual modelling. 

1.3. 1. Lessons from large scale PACS experiments 

Many PACS projects are mainly technology driven or oriented [de Valk 1992, Glass et al. 1991, Goeringer 1991, Irie 
et al. 1991, Mosser et al. 1991]. 

The HiPACS project investigated different issues related to a hospital integrated PACS [Mattheus et al. 1991, Osteaux 
et al. 1992] which are still addressed in the framework of the EurlPACS project. Therefore, the relationship of the 
MIMOSA topic to other parts of the HiPACS and EuriPACS projects is analysed in several of the following sections. 

The PACS project which has had the most experience, as it was one of the first to start, is the UCLA project [Huang et 
al. 1983]. Ten years later Huang and Taira recognised that the "... piecemeal approach did not address all the 
intricacies of connectivity and co-operation between modules. ... The maintenance, routing decisions, co-ordination of 
machines, and expandability of the system became increasingly difficult problems. The inadequacy in (the) design was 
partially due to a lack of understanding of the complexity of a large-scale PACS and to the unavailability of certain 
PACS-related technologies". They advocated an approach which "... relies on building a foundation (i.e. PACS 
infrastructure) for a general multi-media general data management system that is easily expandable, flexible, and 
versatile in its programmability. ... The PACS infrastructure is the basic design concept to ensure that PACS includes 
features such as standardisation, open architecture, capability for future growth, connectivity, and reliability. This 
design philosophy can be constructed in a modular fashion. " [Huang et al. 1992]. 

Their approach presents some similarities with that claimed by the MIMOSA topic. Huang and Taira mentioned that 
"the goals of the PACS infrastructure are to provide the necessary framework to integrate distributed and 
heterogeneous imaging systems; provide intelligent data-base management of all radiology-related information; 
arrange an efficient means of viewing, analysing, and documenting study results; and furnish a method for effectively 
communicating study results to referring physician". 
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1.3.2. Modelling PACS performance 

Modelling has been applied to perform cost-benefit studies of PACS [Andriessen et al. 1989, van Gennip et al. 1990, 
Van Poppel et al. 1990]. Modelling has also been used to simulate a PACS in order to evaluate its performances [Stut 
et al. 1991, Stut et al. 1989]. Other papers present work concerning: performance modelling especially in terms of 
architectural issues [Meyer-Ebrecht 1986], networks for instance to specify hardware of medical image dedicated 
networks [Meyer-Ebrecht et al. 1991] and image databases for instance to assess distributed architecture or archiving 
strategies [Bakker 1993, Sadreddini et al. 1993, Wong et al. 1993]. More details can be found in series of SPIE 
publications "Conference Proceedings on Medical Imaging, PACS Design and Evaluation". 

Although these issues may be critical in daily routine, they are not addressed by the MIMOSA project. 

1.3.3. Conceptual modelling 

The need for modelling PACS, and more precisely the interactions between PACS and administrative information 
systems appeared only after 1985. The first PACS experiments (between 1980 and 1985) were essentially technology- 
driven, and focused on the development of software components capable to communicate, store, retrieve and display 
medical images. Little attention was paid to the functional aspects, and how the systems would actually be used by e.g. 
radiologists in their current clinical practice generally not addressed. The failure of these first experiments led the 
designers to draw the lessons of those non satisfactory systems. Among other reasons, it appeared that sufficient 
functional integration could not be reached unless sufficient inter-operation takes place between PACS and 
administrative information systems (HIS, RIS). As soon as inter-operation is needed between two information systems 
(having different scopes and functions), one has to define explicitly what information has to be exchanged and when 
and what the information means. It means that the co-operating functions must be identified in both systems, and the 
semantics of the data exchanged must be clearly defined. This led a number of teams to model the interworking 
between a PACS and a RIS. The most interesting work in this area was achieved (1987-88) by Siemens and the 
University of Marburg and is generally referred to as the Marburg model. 

1.3.3.1. Marburg model 

The Marburg group addressed the problem of RIS-PACS interfacing, developing a three view methodology of 
modelling and of building the consequent model [Herbst et al. 1988]. Thus the Marburg and the MIMOSA models 
greatly differ as the Marburg model aims at specifying the interface between a PACS and a RIS inside a radiological 
department "not responsible for therapeutic and nuclear medicine functions" [Herbst et al. 1988], regardless of 
specific PACS functions. On the contrary, the MIMOSA model is concerned with all PACS functions involving any 
image provider and consumer, therapy and nuclear medicine included. 

The Marburg approach led the authors to define a set of assumptions [Greinacher et al. 1988] which precisely 
delineate the functions offered by the interface. Consequently, they excluded all the functions related to: image 
operations (handled by the PACS), film tracking, interfacing with image-generating or study interpretation equipment, 
and image-related scheduling. These functions, which are not considered to be within the scope of the Marburg model, 
do belong to the scope of the MIMOSA model. However, some functions addressed by the Marburg model are out of 
the scope of the MIMOSA topic. In summary, the two models are quite different because the Marburg model 
addresses PACS-RIS interface while the MIMOSA model is concerned by PACS functions, e.g. archiving and 
communication. Furthermore, the scope of the MIMOSA model is more general and generic than that of the Marburg 
model. 

The methodology adopted to design these models is similar, although the MIMOSA group have in addition used a 
CASE tool for the automatic checking of the model consistency and documentation management. 

A detailed comparison between the two models and the methodologies used is given in Appendix 1 . 

1.3.3.2. Other work 

The modelling phase aims at consolidating "the data and processing needs of various service centres ... to produce an 
integrated global data structure capable of supporting all PACS applications", [Huang et al. 1992]. The necessity of 
this phase was stressed in an early paper by Zeleznik et al [1983]. Most of the work dealing with conceptual modelling 
focuses on the functional organisation, even if a more or less detailed data model is also included. 
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At UCLA, Huang and Taira [Huang et al. 1992] present such an approach to specify the database, but the resulting 
model is very simple because it mimics the usual paper folder or 'jacket' [Taira et al. 1993]. 

Wendler [Wendler et al. 1992] has specified a data model for his adaptive workstation. This model is more detailed 
than the UCLA model, and is relatively comprehensive. However, this model with its the related data base are local to 
the workstation and are unaware of the existence of any model elsewhere within the PACS. Such a situation can entail 
on the well known "impedance mismatch" effect, and can lead to an inefficient image management inside the global 
PACS. The MIMOSA topic claims that a set of carefully specified data structure and services must be supported and 
distributed throughout the PACS in order efficiently to interface to such an adaptive workstation. Moreover, such a 
structure permits an efficient translation of any internal representation into a more general form allowing full 
interoperability between any application using medical images. 

Udupa et al. [Udupa et al. 1992] note that multidimensional image data are "becoming increasingly common in 
biomedical imaging". Consequently, they propose "an exchange protocol that has been carefully designed ... based on 
and (being) a generalisation of the widely accepted ACR-NEMA" for multidimensional images, but they are not 
interested in the management of such data. 

1.3.4. RIS / PACS integration 

As stated by many authors, the necessity of integrating PACS with HIS / RIS is clearly a key factor for user acceptance 
of PACS in daily routine: to avoid re-entering of patient information on the acquisition systems is the basic 
requirement of such a connection. The prefetching of previous exams or the preloading of new exams into consultation 
and postprocessing workstations on the basis of scheduling information is a more advanced feature which will greatly 
improve the imaging department productivity. Contributing to the organisation of a multi-media patient file is the 
ultimate benefit one can gain from a HIS / RIS - PACS integration. Thus, there exists many publications which address 
this issue, in Europe as well as in Japan or in the U.S. (for example, [Bijl et al. 1987, Levine et al. 1989, Rienhoff et al. 
1987]). 

Some of these publications are very specific and are focused on results from one site, for instance work performed at 
UCLA [Breant et al. 1993], or at Graz [Wiltgen et al. 1993]. 

More generic work exist, either concerning philosophical issues [Bakker 1990, Lodder et al. 1989, Lodder et al. 1990] 
or practical ones. The HIPIN topic, based on some results of the Marburg model, belongs to this latter class. The 
HIPIN objectives were "to design, to realise, to implement and to evaluate an intelligent prototype interface that 
interconnects the existing HIS, including relevant departmental systems (e.g. RIS), with the PACS and the image 
acquisition devices (provided that they can be equipped with such an interface)", [Ottes et al. 1992]. HIPIN is based 
on the fact that "existing PACS and HIS / RIS systems are not suitable to be interfaced directly" and thus, that "the 
task of the basic HIPIN interface is to translate the message sent by one system into a (set of) message(s) that can be 
understood and handled by the other system receiving the messages", [Ottes et al. 1993]. 

As for the Marburg system, from which some of these are derived, the aim of these systems has been dedicated to 
interfacing PACS and RIS. Thus, these systems do not take into account PACS functions nor the integration of 
image-based applications as included in the MIMOSA model. Furthermore, since they are aimed at interfacing, they 
can look like somewhat intelligent gateways communicating requests and data between systems [Soehlke et al. 1992]. 
The MIMOSA model provides a set of services which are transaction oriented. However, as these transactions may 
need access to a RIS (or Departmental Information System- DIS), they enable the interface to be used at the lowest 
level. Thus, these publications about PACS-RIS interfacing indicate that the MIMOSA topic is more complementary 
than competitive. 

Appendix 2 highlights the complementary of MIMOSA and HIPIN approaches for PACS and HIS / RIS 
interoperability. This appendix is extracted from a joint document written by the HIPIN and MIMOSA topics upon 
request from the project officer. 

1.3.5. Early experiments performed by the MIMOSA 
consortium 

Modelling is performed in order to describe a world of interest when designing a database or an information system. 
Thus, as soon as PACS is seen as an information system, it requires the development of a model based on user 
requirements. The functions modelled mimic the actual and current functions of an hospital or an image department 
which handle images and related information. 
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The early experiments of certain participants in MIMOSA (the NRV group) were mainly technology driven. They had 
also studied medical image databases, proposing a uniform representation of images independent of their acquisition 
modality format [Aubry et al. 1988, Bizais et al. 1986, Gibaud et al. 1989]. Then the NRV group realised that "current 
implementations are too strictly limited to administration descriptions and image acquisition parameters and 
consequently are not sufficient to properly represent the whole study data set (medical image meaning of the 
successive series, role and representation of processed images, diagnosis related features, etc.)", [Gibaud et al. 1990]. 
Thus, the aim of the NRV group was to try to integrate such features in a comprehensive, generic and evolutive object 
oriented model, [Aubry et al. 1991, Bizais et al. 1991]. It was suggested that this approach should be used "to define 
the role of medical image data base within health information systems, to list objects to be managed, to model objects 
and propose formal interfaces, to validate models and to propose practical implementations", [Bizais et al. 1991]. 
Thus the resulting medical image management system is seen as a subsystem of a medical information system, able to 
handle the specific nature of medical images. This standpoint disregards the current frontiers between the different 
information system components (PACS, HIS, RIS), [Gibaud et al. 1992]. 

The Geneva PACS project is one of the most important European PACS projects. Its aim was "to develop an 
integrated image management system for radiological as well as non radiological images ... In this architecture, the 
images are viewed as another type of information to be handled by the HIS. ... The PACS is based on a distributed 
architecture of large number of servers." [Ratib 1992]. In this architecture, communication, storage, display and 
processing functions are tightly coupled, and have led to specific developments such as the PAPYRUS file format 
[Ratib et al. 1990, Ratib et al. 1993] and the OSIRIS software [Ligier et al. 1991]. At this moment, the PACS and the 
Geneva HIS (DIOGENE) are loosely coupled. 

Many members of the MIMOSA consortium are involved in European standardisation committees concerned with 
medical informatics (CEN TC 251: Rennes for NRV, London for LLB, GEMS and Geneva; COST B2: Brussels). 



1.4. Expected results 

For the above reasons, the research being performed in the framework of the MIMOSA topic constitutes a necessary 
step for designing and implementing PACS since: 

1. The model is developed on the basis of functionalities required by end-users, such that the resulting PACS are 
likely to fulfil the medical imaging community expectations, rather than being only feasible from a technological 
viewpoint. 

2. Image management is defined as a subset of medical information management, such that the distinction between 
subsystems, such as HIS, RIS and PACS, is not based on technological aspects, but rather on clinical 
requirements. It follows that the exchange of information between subsystems is a consequence of these clinical 
needs, rather than induced by technological requirements. The interface between PACS and RIS is directly built 
into the model; it is not added later on in order to allow communication between independent systems. 

3. The model requires the semantics associated with the various concepts to be made explicit. It should facilitate 
interoperability between the various subsystems of the medical information system, and enable meaningful 
exchanges of data between various institutions located in various countries. 

4. Users' requirements are essentially incorporated in the data and functional models such that proper generic 
functions can be defined. Features specific to institutions or countries are mainly located in the dynamic model. 
In this way, only by abstraction and decoupling of functional, organisational and implementation aspects, it 
suggested that the design and implementation of cost effective PACS can be achieved. This method should 
greatly assist companies to design PACS as a product or a product line, well suited to a large variety of 
modalities (CT, MR, DSA, SPECT, CR ...) and medical specialities (cardiology, neurology, surgery, 
radiotherapy, ...). Moreover it should permit low maintenance costs, and easier system updating. 

In summary, while the MIMOSA model may seem very theoretical and far away from primary concerns of the medical 
imaging community, the MIMOSA topic group believes that such a model is an absolute necessity for PACS to be 
successful both for end-users and medical imaging companies. Moreover it is complementary to and should assist the 
more applied research topics in the EurlPACS project. 
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1.5. Original aspects of the MIMOSA 
model 

1.5. 1. A generic image management model 

It is not enough to provide the appropriate technology (networking, large archiving systems) to build a successful 
PACS system [Saranummi et al 1992]. It is also necessary to specify the data to be managed and the functions 
operating on them. It has been recognised that a model able to consider medical images as a subset of medical 
information and able to address the specific aspects of medical images is required to build PACS. Such a model was 
not available. Moreover, to be useful, this model had to be generic enough to be accepted by a wide community. 
Developing such a model was the goal assigned to the MIMOSA consortium within the AIM programme. 

The MIMOSA model is therefore a generic model of medical image management system 

1. Application-independent: independent from medical specialities and local specificities in order to make it 
acceptable to medical image users in general throughout Europe, 

2. Implementation-independent: in order to allow its implementation by many different companies in various 
environments, and to cope with rapidly evolving information technology. 

3. Based on a medical image user viewpoint: in order to avoid bias induced by a technology driven approach. 

4. Based on an open system architecture: in order to focus on medical image specificities while allowing 
interoperability with other medical information systems. 

Such an approach is original to the extent that several major participants in the field of medical imaging suggested that 
such a model could not be defined at the time when the project was started. It might also be suggested that such an 
approach is also too theoretical to be of good practical use. In fact, the contrary seems to be true. The MIMOSA topic 
group believes that this approach is essential for developing satisfactory industrial, commercially successful PACS for 
the following reasons. 

Manufacturers know (at last) what users actually expect from PACS. From generic user requirements, they can specify 
a general PACS architecture (i.e. a product line) able to communicate with other medical information systems. Since 
identical PACS implementations cannot satisfy all users, using this approach the resulting systems can be easily 
tailored to local user needs. This approach results in a dramatic reduction of development costs and facilitates 
interoperability between PACS. 

The MIMOSA model is based on a functional model (the functions required to manage medical image data), a data 
model and a dynamic model (in which order and according to which constraint basic functions are used). Three 
original aspects of these models are summarised in the following sections. 

1.5.2. Data availability 

The availability of image data at the right time in the right place is a key point in getting PACS accepted. Instead of 
defining data availability in terms of network throughput and disk access time, as is handled in technology driven 
PACS approaches, here, data availability is determined in a deterministic way: data availability requests are issued 
explicitly by users or by the system itself in the course of performing imaging procedures. This results in a 
deterministic and unified approach to prefetching, preloading and layered archives. Moreover this approach is 
implementation independent such that the model is valid even when the underlying technology significantly evolves. 

1.5.3. HIS / RIS / PACS interoperability 

In this field the MIMOSA model addresses certain issues already raised in the HiPACS project. Contrary to the 
suggestions of the HiPACS project, which proposed a bottom-up approach which gave rise to the HIPIN topic of 
EuriPACS, MIMOSA makes use of a top-down approach based on the following assumption. Medical images are a 
subset of medical information. Depending on the environment in which images and additional information are used, 
medical images may be handled by different information systems. It follows that MIMOSA must also specify the non- 
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image data to be used by PACS and the functions which process them. It is not the purpose of a model to specify 
where they must be stored. In other words the MIMOSA model refers to functions needed to handle medical images, 
and not to systems where such functions could be implemented. In this way it is consistent with the Nucleus / Riche 
model and complementary to that topic. 

1.5.4. The Image kernel 

Another important aspect of the MIMOSA model is the way images themselves are described. The image kernel 
specifies images produced by all modalities and of any dimensionality. These features are required as a result of the 
need to convey all the semantics of images and to provide processing and display programs located in workstations 
with a unified description of images. To our knowledge even although similar approaches have been published, none 
of them reaches the generality and the genericity of the MIMOSA image kernel. This approach is consistent with the 
long term goal of CEN / TC25 1 / WG4 and the philosophy of IPI. Moreover the image kernel distinguishes threee 
description levels: formal, version, representation levels which allow application programs to consider images with 
respect to the most appropriate description level. 

1.6. Relationships to other EurlPACS 
topics 

The MIMOSA topic aims at modelling the image information as a subset of medical information. Inevitably it shares 
some research fields with other EurlPACS topics. However the approach taken by MIMOSA is somewhat different 
and should result in some interesting viewpoints which are complementary to those of the other EurlPACS topics: 

1. HIPIN and MIMOSA are both concerned with the integration of HIS/RIS and PACS. Both topics have 
modelled this integration at different levels according to their respective goals : focusing on implementation 
issues in the context of the existing HIS / RIS and PACS, the HIPIN model was intended to be the basis for the 
prototyping of the HIPIN interface. The long term viewpoint of the MIMOSA topic provides a comprehensive 
formal model at the conceptual (data and functions) and dynamic levels as detailed in appendix 2. During their 
modelling phase, MIMOSA and HIPIN benefited from each other's work since the HIPIN study concept (for 
example) is based on the MIMOSA'S definition and the MIMOSA functional model takes into account the results 
presented in the HIPIN Deliverable A. 

2. DIDATA focuses on how to organise efficiently distributed medical image databases (i.e. technological aspects). 
The DIDATA results will be of great interest for the development of a MIMOSA-based Image Management 
System since MIMOSA considers distributed data bases as an efficient means to implement a large and complex 
data base (i.e. user's viewpoint). 

3. IMPHONE aims at developing a particular application concerning the communication of images and the 
associated information between remote users. In this context MIMOSA provides the data structure and 
communication mechanisms on top of which the IMPHONE application is developed. It is the purpose of the 
Luxembourg - Pisa implementation to validate the MIMOSA opinion request related data and functional models 
as described in section 5.2. The ability of MIMOSA to cope with specific communication requirements is clearly 
demonstrated along with portability and interoperability of the MIMOSA kernel and the MIMOSA based 
applications. 

4. TEASS deals with the impact of PACS on organisations. To that end, one needs a functional description of the 
organisation. As this organisation involves activities which can be performed by future Image Management 
Systems, TEASS and MIMOSA models are partially overlapping. 

5. INDENT aims at defining image attributes usable to index and retrieve images on the basis of image content. 
This is a good example of application-defined image attributes which can be described by the MIMOSA data 
model. 
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1 . 7. Working methods 

The tasks achieved by MIMOSA to build an open system are strongly related to the ISO Open System Conceptual 
Modelling Methodology (figure 1.7-1). It leads to organise the topic in five workpackages. 

1) The first workpackage (WP 1) was dedicated to the management of the project. 

2) The second workpackage (WP 2) which corresponds to the "Business Rules and Organisational Requirements" 
consists in interviewing users and actors and realises the synthesis of their needs. 

3) The third workpackage (WP 3) consists of conceptual modelling including "Business Rules & Semantics" and 
"Functional capabilities & support services". The Business Rules and Semantics focus on high level operations and 
their associated requirements and constraints, as seen from the user's perspective. The functional capabilities and 
support services focus on the mechanistic requirements for organising the operations described within the business 
view. It is base on a common terminology to avoid confusion. 

The model comprises three layer aspects: 

• The first layer includes general information, such as referring physician attributes, patient attributes, medical 
history, modality independent examination attributes (examination requests, examination reports,...) which can be 
shared by the different subsystems in charge of appointments, billing or medical records. 

• The second layer is modality oriented. Its entities are related to acquisition techniques and image processing. This 
level is more difficult to model, because: 

- each modality may have its own specific attributes; 
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- the acquisition type, the image processing description and their resulting derived images are a priori 
unknown and may evolve. 
• The third layer concerns the management context. 

Functional modelling lists and describes the services performed by the MIMOSA system. 

The model describes the way entities are built and their behaviour rather than describing the entities themselves. 

The model is tested and validated using a number of simple and complex clinical cases, which portray some real 
clinical situations. 

4) The fourth workpackage (WP 4) concerns standards. Such standards have been taken in to consideration and used 
as far as possible. This workpackage is concerned with the relationships between MIMOSA consortium and other 
groups working on standards, especially in the medical field. 

The modelling has been performed taking into account existing standards (ISO, DICOM, Interfile, etc.) and efforts 
were made to feed information back into the current standardisation processes in the area of medical informatics, in 
particular domain of medical imaging (CEN TC251 - WG4, and the future releases of the DICOM / MEDICOM 
standard). 

5) The fifth workpackage (WP 5) corresponds to the "Open System Implementation". The MIMOSA implementation 
in the real world requires an architectural choice based on standards reviewed previously and satisfying the function 
defined within the model. Prototypes are implemented in order to demonstrate the feasibility of the approach, and 
prove the validity of the concepts introduced in the conceptual modelling phase. 



1.8. Organisation of the deliverable 



1.8. 1. General content of the deliverable 

The deliverable is organised into two parts: 

-Part 1: MIMOSA achievements. This describes the MIMOSA concepts and the methodology to understand the 
results of the four workpackages of the MIMOSA topic. 

- Part 2: MIMOSA appendices. They give an in-depth view which is necessary to exploit MIMOSA results. 

1.8.2. Content of part 1: MIMOSA achievements 

- Section 1 : Introduction. 

- Section 2: "Requirements review and definition of terms". The Workpackage 2 is based on interviewing medical 

imaging experts (clinicians, radiologists, computer scientists) in order to collect users' requirements and 
definition of terms. A summary of the results is given here in order to explain choices made in the 
model, to define terms used in the model, and to recall basic questions as yet unanswered at the 
beginning of the MIMOSA project. 

-Section 3: "Conceptual modelling and specifications". This section presents the modelling methodology, that is, it 
gives the rationale of the modelling and its components. The context of the MIMOSA system which is a 
part of the model describes the external entities in interaction with MIMOSA. The conceptual model 
(data model) is explained. It is divided into three main parts, the examination context, the image kernel, 
and the image management model. Then, the functional model describes how MIMOSA functions 
manipulate the NIAM sentences of the data model. Image acquisition, processing, interpretation, 
reporting and viewing have been described. At least, the dynamic model organises functional relations 
into scenarios including considerations such as sequencing, time constraints and error handling. 

-Section 4: "Standards assessment and architecture". Here the interactions between the MIMOSA and the existing 
standards are described, how they helped, and where there problems exist. 

-Section 5: "MIMOSA prototypes at Rennes and Luxembourg / Pisa". The two prototypes developed, in order to 
validate the concepts that were modelled with MIMOSA, are described. 

-Section 6: "Conclusion". 
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- Section 7: "Publications and communications". 



1.8.3. Content of part 2: MIMOSA appendices 



Appendix 1: "Comparison between the MIMOSA and Marburg models". The in-depth explanations about the 
Marburg model and comparison with the MIMOSA approach. 

- Appendix 2: "Comparison between HIPIN and MIMOSA approach to HIS / PACS Integration". The comparison 

between MIMOSA and HIPIN approaches. 

Appendix 5: "MIMOSA data model: graphics and comments". A detailed presentation about the data model. 

Appendix 6: "MIMOSA functional model: graphics and comments". A detailed presentation about the functional 
model and the context diagram. 

-Appendix 7 "MIMOSA dynamic model: graphics and comments". A detailed presentation about the dynamic 
model. 

Appendix 8: "Clinical examples". It is not considered that clinical examples are in themselves sufficient to 
validate the MIMOSA model. However it seems appropriate to include several clinical cases to 
illustrate how the MIMOSA model works and can model rather complex situations usually 
considered as difficult. These clinical cases have been drawn from real cases personally dealt with by 
physicians participating in the MIMOSA topic. In fact, clinically oriented readers may well read this 
section first; they may find it easier to understand the abstract concepts of the previous sections. 

- Appendix 9: "Comparison between MIMOSA and DICOM data model (examination context)." 

- Appendix 10: "Comparison between MIMOSA and DICOM functional model." 
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This work was performed during the preliminary phase of the MIMOSA model (i.e. WP 2 of the MIMOSA topic). It 
was dedicated to elicit the main concepts and functions involved in image communication and handling. These 
concepts and functions were used as the basis of the modelling. However, some of them appeared to be too specific 
relatively to the MIMOSA aim (e.g. stay or visit), while others came out during the modelling phase even if they had 
been implicit in that reviewing phase (e.g. the data availability concept). 



2. 1. Methods 



2. 1. 1. Requirements review and terminology 

The first step of the work carried out within the MIMOSA topic consisted of describing the universe of discourse, that 
is, to specify: 1) the various procedures of creation, utilisation and management of biomedical images, 2) the actors 
involved in these procedures, and 3) the data to be managed (images and related data). This review was intended to be 
comprehensive, not limited to diagnostic radiology, but to cover the whole domain of biomedical imagery (including 
nuclear medicine, endoscopy, pathology, ophthalmology, etc.), in clinical use as well as in teaching and research. In 
addition the study was performed in several different European hospitals, in order to evaluate the extent of local 
variation. 

The general methodology used was as follows: 

1 . Gather information from users 

2. Try to identify common concepts 

3. Detect and identify problems 

4. Decide whether unifying concepts could be found 

5. Decide terms of reference 

2.1.1.1. Gathering information from users 

Information (the description of real world objects) was gathered using the experience of experts participating in the 
project and by means of interviews with medical imaging specialists (radiologists, nuclear medicine physicians, 
clinicians, surgeons, pathologists, archive managers, medical image processing specialists, etc.). 

2. 1. 1.2. Trying to identify common concepts 

Many ambiguous terms and terminology problems were rapidly identified and, as a result, this work turned out to be 
more difficult than expected. In fact it was realised that the terms in general use have almost no formal definitions and 
with semantics that are very context dependent. In daily practice this does not cause trouble since, using natural 
language, human beings resolve the problem by integrating a lot of contextual information. 

2. 1. 1.3. Detecting and identifying problems 

Several kinds of problems have been encountered: 

1. First, several terms may be used to describe the same concept (synonyms). This is very common both within a 
given discipline and across different disciplines. Simple translation problems (between two languages) also often 
belong to this category. A detailed analysis was often necessary to decide whether different terms actually 
referred to the same concept. 

2. A second possibility occurred when a single term referred to several concepts. This is very frequent when 
comparing usage between different disciplines. For example the term study seemed to have different meanings in 
nuclear medicine and radiology. For radiologists, a study may be a synonym of procedure or examination, 
whereas in nuclear medicine study may refer to several examinations contributing to a common diagnostic goal. 
Another example is provided by the term raw data in CT. For radiologists, raw data are the first images provided 
by the CT, whereas image processing specialists consider that the term raw data refers to the acquired data (i.e. 



-20- 



— Requirements review and definition of terms — 



data before reconstruction). 3-D image may also be an ambiguous term; some people call 3-D images the sagittal 
and coronal slices reconstructed from a series of axial images, whereas, for other people, 3-D images are the 
shaded display of 3-D surfaces derived from a 3-D data set (showing the skin or the skull, for instance). 

3. A third situation occurred when in depth discussions were not sufficient to clarify the underlying concepts 
entirely. The concepts themselves were 'fuzzy'. For example, trying to obtain a formal definition for an 
Information System (such as RIS, HIS, PACS) has raised such problems; the definition can be very different 
depending whether the concept of Information System (i. e. a number of information processing mechanisms 
aiming at producing new information) or that of a physical system supporting the Information System, is 
considered. The attitude adopted in such cases consisted in refocusing the discourse on to the user needs which 
are independent of implementation issues. 

4. Another class of difficulties was also encountered when the end-users introduced concepts related to 
implementation. This was particularly the case in discussions about image storage and archiving. Users' 
experience led them to refer to the physical aspects of storage (storage media such as magnetic or optical disks) 
rather than functional aspects (which data are needed, when, how fast do they have to be retrieved, etc.). In this 
particular case, end users were invited to formulate their needs in terms of information availability and relevance 
to a particular task, rather than in terms of the capacities of workstation hard disks, or network throughput. 

2. 1. 1.4. Deciding whether unifying concepts can be 

found 

In most cases a detailed discussion was sufficient to clear up ambiguities, and non-ambiguous terms could be agreed 
upon. Nevertheless, some situations occurred where it was not possible achieve this. This was the case for instance 
when similar tasks (such as film transportation) were fulfilled by different categories of personnel in different countries 
(technicians, nurses, secretaries). The underlying question was to decide whether one should focus on the tasks or on 
the personnel categories. 

2. 1. 1.5. Choosing terms of reference 

In practice, it was sometimes difficult to make a choice between several different terms since there was a natural 
inclination to select the more popular ones. Unfortunately, those terms were often more ambiguous and their meaning 
very different from one discipline to another. However, this is not so important in that the major advance desired was 
to achieve a common commitment with respect to the concepts as opposed to the terms, which are essentially a 
convention. The objective was certainly not to impose new terms on a community of people, but to remove ambiguities 
on their use of terms which might jeopardise the consistency of the model (and thus of the future information system). 

2. 1.2. Scenarios and image management 
functions 

When users describe their activities, they generally describe Scenarios i.e. the succession of operations during which 
information is produced, processed, used, managed, for particular purposes (patient care, research, teaching, etc.). For 
instance a scenario may refer to the successive steps of patient care from the diagnostic, up to the therapeutic and 
follow-up stages. As far as the management of medical images is concerned, it is essential to take into account these 
scenarios in order to guarantee the availability of relevant data when they are needed. 

The problem here is that the description of such scenarios is very difficult in that they are potentially very numerous 
and strongly dependent on the medical speciality (e.g. intensive care, ophthalmology, neurosurgery) and institution. 
Moreover, even in a given discipline, scenarios may be disease-dependent. For example in neurosurgery, scenarios 
related to patients suffering from a cranial traumatism will certainly be different from those concerning patients treated 
for a cerebral tumour. 

The extreme variability of such situations makes the exhaustive description of scenarios impossible. Nevertheless, the 
analysis of some showed that a small number of elementary functions could be listed and described. So, it was decided 
to focus on those elementary functions requiring the co-operation of several actors (such as archiving data in the 
system memory, communicating between physicians, prefetching, retrieving information from system memory, etc.). 
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2.2. Results 



This investigation is reported in Appendix 3 entitled: "MIMOSA Operational Requirements". The first part dealt with 
terminology and gave a number of definitions concerning: 

1. The actors involved in P ACS: 

- patients 

- examiners 

- physicians and surgeons 

- technicians 

- nurses 

- secretaries 

- referring physicians 

- technical support managers 

- image clerks 

- library clerks 

- administrative personnel 

2. The main concepts related to diagnostic imaging: 

- stay 

- visit 

- investigation 

- image study 

- examination or procedure 

- multimodality 

- images 

- examination request, schedule and report 

- examination session 

3. The image management related information systems, being: 

- Hospital Information System 

- Radiology Information System 

- PACS 

and finally, 

4. The major components of a PACS: 

- imaging equipment 

- workstation 

- hard-copy system 

- PACS memory 

The second part dealt with the major functions PACS must fulfil. Functions actually perceived by end-users and 
internal functions which are transparent to the users were distinguished. 

1 . Functions actually perceived by the user: 

1.1) Information retrieval functions: 

- consultation by work list 

- consultation using demographic -type criteria 

- consultation using clinical criteria 

- mailbox collection 

1.2) Communication functions between users: 

- routing of new exams (initial data) 

- transfer of a processed exam to a referring physician 

- real-time opinion request 

- non-interactive opinion request 

1.3) Storage functions: 

- saving of initial data 

- saving of processed data 

1.4) Hardcopy functions: 

- data transfer between acquisition devices and the hardcopy system 
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- data transfer between workstations and the hardcopy system 

- data transfer between the PACS memory and the hardcopy system 

2. Other functions managed by PACS: 

2.1) PACS memory management functions: 

- data transfer to a higher level of availability (prefetching) 

- data transfer to a lower level of availability 

2.2) Exchanges with HIS/RIS: 

- data transfer between image acquisition devices and RIS/HIS 

- data transfer between a workstation and RIS/HIS 

- data transfer between the PACS memory and RIS/HIS 

The document was circulated outside the project team to gather additional comments. Two general remarks were 
made. The first was that "the MIMOSA viewpoint is strongly influenced by radiological practice. The point of view of 
clinicians seems to be underestimated and specific domains such as support to clinical research, teaching and quality 
control seem to be almost ignored". A second remark was that, in spite of the collaboration of specialists from several 
countries, "some definitions are very specific to a given country (namely France)". The fact that some kinds of 
personnel (such as technicians, nurses) may have very different roles (with respect to image management) in the 
various countries, may certainly hinder the design of a comprehensive model. 

At that early stage of the project, the objective was certainly not to bring definitive answers but to highlight such 
difficulties so that they could be properly addressed by the people in charge of the modelling task. 
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This chapter is intended to present the basic assumptions of the model, the methodology used to build the model, and 
the main features (in terms of concepts, functions and dynamics) of the model. 



3. 1 . The model scope 

3. 1. 1. The two views about the domain of medical 
imaging 

Two main views about the domain of medical imaging can be defined. 

The first one can be called the HIS / DIS (Hospital Information System / Departmental Information System) view, 
which considers medical imaging information as a subset of medical information in general. This view focuses on the 
context in which image information is produced and used, rather than on images themselves. The second view may be 
called the image centred (or PACS) view, which aims at providing a means to manage, communicate and understand 
images themselves produced by acquisition and processing devices, without being concerned as to why and how such 
information is produced. 

Clearly each viewpoint is too restrictive: the HIS / DIS view because it does not take into account the special nature of 
images, the image centred PACS view because it focuses too much on it. 

The MIMOSA approach essentially consists in merging the two viewpoints, and in recognising that image information 
can be manipulated by various systems for different purposes. The MIMOSA model specifies the items and the 
functions being used when image examinations and images are manipulated in various medical contexts. However, it 
does not care about whether the item management and the function is undertaken on the responsibility of the HIS / DIS 
or the PACS system, nor about the platforms involved in the process (implementation independence), nor about the 
specific reason why these items are being manipulated (application independence). 

Hence the scope of the MIMOSA project is intended to be sufficiently general to cover a large spectrum of 
applications. 

3. 1.2. Holistic approach 

The MIMOSA system can get information from other information systems such as HIS / DISs, and provide 
information to them, so that an external information system and a MIMOSA system can cooperate to manage images 
and related image information and provide users with image information. Such processes are described by the 
functional and dynamic models, operating on data described in that part of the data model called the examination 
context. Concepts common to an external information system and a MIMOSA system must be defined, such that they 
both understand these concepts in the same way. It does not matter whether such items are usually considered as items 
belonging to the external information system or to the MIMOSA system, and whether they are located in the HIS / DIS 
or the PACS for a given implementation. They just have to be understood in the same way by both systems. 

On the other hand, a MIMOSA system must be able to manage images produced by acquisition devices, processed by 
workstations, and stored in large archiving devices, for which purpose a set of items must be defined. These specify 
image characteristics and the relationships between images. They essentially form part of the image centred viewpoint. 
Utilisation of medical information in general, and medical images in particular, is closely related to the different 
clinical activities. It follows that supplying a uniform and consistent way of image management without including 
image availability management is not sufficient. This availability management can be analysed in a deterministic way, 
provided that sufficient organisation exists to determine, or at least to estimate, which data are needed, for which users, 
when and for how long. This macroscopic management provides constraints on performances, workloads and 
functioning of the actual networks, distributed storage and data bases systems. It does not claim to replace network or 
data base management tools neither to provide prefetching or preloading rules. 

In summary, the MIMOSA approach considers image information from a holistic (system approach) viewpoint. The 
MIMOSA approach defines image related information and information flows in order to manage image production in 
imaging departments and its use in clinical and surgical departments for medical, teaching and research purposes. 

The MIMOSA project can be placed in context as shown in figure 3.1.2-1. 
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figure 3.1.2-1: The MIMOSA project and its environment. 

Vertical arrows represent relationships between data types, i.e. data structure within the MIMOSA system. Horizontal 
arrows represent data flows, i.e. data exchanges between the MIMOSA processor and its environment. Thin black or 
gray arrows are related to main imported data. Bold arrows deal with exported data, i.e. essentially medical images 
and their related parameters. 

3. 1.3. Generality of the model 

The MIMOSA topic aims at providing a conceptual framework of image management for the variety of situations 
involving medical image use. It is claimed to be application and implementation independent, and comprehensive 
since it includes all facets of biomedical image handling, both computer and paper based. Consequently, the MIMOSA 
topic proposes a general model, independent of specialities, organisations and implementations. Moreover this model 
has been designed with a prospective viewpoint, which means that the model is intended to take into account how 
images are likely to be managed in the future rather than being restricted to how they are managed today. This should 
satisfy the users' functional requirements while taking into account the general tendency (desire) to replace film-based 
systems by digital ones. 

However, in a number of situations, several solutions could be proposed which seemed to be equivalent; the same 
'observations' could be modelled in different ways. In such cases the choices we have made may seem somewhat 
arbitrary. 

In other cases where several solutions exist, choices had to be made which are specific to a particular organisation or 
service although not relevant in other contexts. For instance, some aspects of the model are relevant to diagnostic 
radiology but not to surgery planning. 

Whereas the first remark does not reveal a real problem, the second indicates that a sufficient level of generality could 
not be achieved. In fact a difficult trade-off had to be made between the objectives of precision and consistency, and 
generality of the model. The need for precision and consistency forces one to use a slightly restrictive terminology and 
imposes a number of constraints, whereas generality leads one to fuse together concepts into more general forms and 
to choose more flexible constraints. 

So, the models must define a minimal set of concepts, in the following sense. A minimal set implies that a single 
generic item is preferred to the use of several (perhaps more specific) items, even though the resulting construct may 
be more difficult to understand. In this way, when this small set of concepts is understood, a comprehensive, unifying 
understanding of image management, archiving and communication may be achieved. In addition a small set of 
concepts makes the model easier to maintain, and more application independent. 
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3.2. The modelling methodology 



3.2. 1. Introduction 

The MIMOSA topic aims at providing a framework to implement an information system dealing with the exchange 
and the management of medical images within the context of the general organisation of medical information 
processing and management (figure 3.2.1-1). For now, such an information system, based on the MIMOSA model, is 
called for the sake of simplicity "a MIMOSA system". Consequently, although the MIMOSA topic is not intended to 
describe the whole (of such an) organisation, it cannot be considered independently of it. The organisation can be 
shown as a set of interrelated organisational units, often defined by their function (e.g. laboratories, image 
departments, surgery departments, clinical departments). These units process and exchange each other and with the 
external world, various kinds of data such as medical or technical reports, images, lab data, scheduling data 
(figure 3.1.2-1). This set of units and their relationships compose a system. Indeed, Boute [Boute 1988] defines a 
system as "a collection of physical objects (subsystems) that interact each other and with the environment through 
(physically identifiable or conceptual) interfaces". Le Moigne [Le Moigne 1991] gives the following definition "A 
system is: a collection of elements or components, endowed with a structure, which realises functions; which 
transforms matter, energy or information; which evolves through the time, in an environment, according to a set of 
purposes". 

According to this view, a MIMOSA system can be considered as a processor located within image departments, which 
exchanges data and offers services to its environment composed of medical image users, or actors. Thus, the 
MIMOSA system has to cope with the nature of exchanged data, the nature of offered services, the way how services 
are requested or performed and, the way that data are received, processed and sent on. 

As the MIMOSA system is complex, a method is required to assess the system and verify that it satisfies users' 
requirements before implementing it. Such a method cannot be based on real programming languages as they force the 
specification of implementation details which are useless in the understanding of the system. When starting directly by 
programming (encoding) software, crucial aspects of the system are hidden and cannot be correctly addressed. 

To understand such a system, and to deal with its complexity, the system must be abstracted. This abstraction isolates 
important aspects, relevant for the system use, and suppresses non essential details. The purpose of the modelling 
process is to support this abstraction. 

The following paragraphs explain how the overall MIMOSA model was built in order to match the above view of the 
MIMOSA system. The MIMOSA model is composed of three submodels, say a data model, a functional model and a 
dynamic model. The first paragraph deals with the cycle of the modelling process. The second paragraph introduces a 
layered analysis of the model. The last paragraph describes its different components. 

3.2.2. The modelling process cycle 

During the model building, various types of interrelated skills (figure 3.2.2-1) are requested, being those of: 

• The final users of the resulting system, to define the functional and non-functional requirements, to specify 
adequate performance and to evaluate prototypes. 

• The designers, to build the model, assess the technology and choose architecture for implementation. 

• The developers interested in standardisation, software and hardware technology, and the various aspects of 
system management and implementation. 

Thus, the model is based on the use of expert interviews to elicit present and prospective users' needs. 

This task was addressed by the workpackage 2 (WP 2) of the MIMOSA topic. This preliminary work has served as a 
starting event for the modelling process. The model was iteratively built from new inputs, such as draft standards and 
expert interviews on specific fields encountered during the modelling process. It was iteratively assessed using actual 
clinical cases provided by clinicians participating in the MIMOSA topic. The modelling task was within the scope of 
the workpackage 3 (WP 3), and the standard related issues were dealt with by workpackage 4 (WP 4). Certain parts of 
the model are evaluated using prototypes (workpackage 5, WP 5). This implementation has necessitated a phase of 
assessment of the current technology, to determine suitable architecture and to estimate their related performances with 
respect to the present technology. 

The model building was based on a three, more or less interleaved, step processes: 
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1) The preliminary study has specified the scope and the context of the modelling task, with three objectives: to 
provide general guidelines and references, to identify concepts and relationships relevant to the universe of interest, 
and to list external constraints. 
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figure 3.2.1-1: Layers of modelling IMS, and their meanings. 

The conceptual model concerns what one wants to model without regard to how the final system will be implemented. 
It is the actual modelling process of the MIMOSA system (WP 3). The internal layer deals with the topology, or 
organisation, of the actual system and with implementation issues. It is mostly within the scope of WP 5. WP 4 deals 
with some model and architectural issues. 
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figure 3.2.2-1: Abilities involved in the MIMOSA topic development. 
2) The design phase has delivered the detailed, verified and completed conceptual model of data, functions and 
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their dynamics. The dynamic model organises functional relations into scenarios including considerations such as 
sequencing, time constraints and error handling. 

3) The organisational phase partly overlaps the dynamic model building. It aimed at implementing concepts into 
data structures, and functions into service structures and at checking if the produced structures cover all organisational 
and system requirements. 

Security issues and scenarios are not included in the MIMOSA model because they depend on the local culture at each 
implementation site. Only, structures and methods allowing implementation of access control mechanisms are 
specified. 

Since the system to be modelled is complex and overlapping domains of skills are required, a stepwise iterative 
process must be used. It allows the model refinement and the feedback between the various abilities involved. 
Technology assessment and evaluation have also supplied feedback to refine the model. The stepwise process was 
repeated until satisfactory agreement between the extent of the model and the users requirements was finally reached 
(figure 3.2.2-2). 
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figure 3.2.2-2: The MIMOSA model building cycle. 
See the text for explanations. 



3.2.3. The modelling of an information management 
system 

As the MIMOSA system is an information system, its modelling must comply with the general methodology of 
information management system (IMS) modelling. This methodology needs the setting up of a common language 
between all people involved in the model design. It begins with the delimitation of the system scope before the 
conceptual description of the system can start. 

3.2.3. 1. The need for a common language 

Before starting the modelling of an IMS, all actors, (e.g. users and designers) must agree upon a common language, 
i.e. a common set of signs or words in order to encode the model. This set of words can be created using graphical 
composition rules as provided by most Computer Assisted Software Engineering (CASE) tools [Gibson 1989, McLure 
1989, Orr et al. 1989]. A formal language such as Z [Abrial 1980] or VDM specification languages can be employed. 

However, as mentioned by Nijssen [Nijssen and Halpin 1989], "Besides the requirement for a common language, 
effective communication between two speakers requires that each speaker gives the same meaning to the words being 
used. This can be achieved by ensuring that both speakers (a) share the same context or universe of discourse, and (b) 
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speak in sentences that are unambiguous with respect to this universe of discourse." 
Hence, an unambiguous dictionary of terms must be constructed. 

3.2.3.2. Three abstraction levels 

As pointed out by various authors [Olle et al. 1988, Pichat and Bodin 1990, Scheer 1992], the description of the 
system involves at least three levels of abstraction namely: external, conceptual, and internal. 

The external level describes the view that a class of users has on the data, i.e. the data subsets and their access rights, 
and how this view relates to the conceptual level. It allows the definition of the interfaces with the external world, and 
the specification of the users' class profiles. This level was addressed by WP 2. 

The conceptual level is the most fundamental because it portrays the Universe of Discourse (UoD) in a way that is 
meaningful to humans. In linguistic terms, it deal with the grammar of the UoD. It takes into account the syntax and 
the semantics of the object populating the UoD. It describes data structures, integrity or consistency constraints and 
global management rules (e.g. data relationships). It also specifies all the permitted states and transitions of the IMS. It 
does not directly refer to any use, any user and any physical access or implementation. This level is covered by the 
conceptual modelling process (WP 3) and is described in this chapter.. 

The internal level includes a logical level and a physical level. It specifies the implementation, in terms of hardware 
and software resources. It is mainly within the scope of WP 5. 

3.2.3.3. The conceptual level description 

This level deals with the data, their processing and their communication. It is centred on a model where data are 
described as structures, processing as procedures and communications as protocols. This description results in a data 
dictionary which must be as precise and relevant as possible, updatable, consistent and non-redundant. 

The conceptual database (called the "conceptual information base" by the ISO organisation), associated with this layer 
is defined by the sets of data populating the system, at a given time, i.e. it contains instances of concepts that have to 
be modelled. Parts of this base can be used to illustrate the data dictionary. 

The technical aspect includes the hardware, the software (e.g. languages, data bases, libraries) and the documentation 
support for the model building. In other words, it concerns the building tool. 

The description can be analysed from different viewpoints, each of them leading to special kind of model using 
appropriate description languages. 

3.2.4. The model components 

As mentioned by standards organisations (ISO and ANSI), various points of view on the UoD must be taken into 
account during the different phases of modelling. They are summarised in table I. As the IMS is a processor 
transforming input data into output data, data and processing must be considered simultaneously. 

As claimed by IFIP (International Federation for Information Processing) WG 8.1 (Information Systems. Design and 
Evaluation for Information Processing) [Olle et al. 1988, Scheer 1992], conceptual data modelling involves two 
aspects: 

• it establishes the list of entities involved within the UoD (data as well as processing), 

• it normalises these entities by a refinement process. The normalisation process has a different meaning according 
to the underlying methodology. For instance, normalisation rules for the relational data model are not the same as 
those for object-oriented models. 

Process modelling can be seen from two complementary perspectives. The first focuses on relationships between the 
system and its external interlocutors and, as well as, between the internal functions of the system. The second deals 
with the temporal behaviour of the system. 

This approach emphasises that each component of the system plays a specific role in relation to other components. It is 
opposed to structured analysis approaches (e.g. the Jackson one [Sutcliffe 1988]), which isolate each component by 
applying hierarchical decomposition. 

Data and processing modelling results in the creation of three kinds of cross linked models (figure 3.2.4.-1): the data 
model, the functional model, and the dynamic model, which are necessary to describe completely the IMS from the 
point of view of its structure, its functions and its dynamics. They are relevant to all stages of the development of the 
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IMS. 

In order to help designers, these models are often graphically represented using specific formalisms. 
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figure 3.2.4-1: Models involved in the modelling process, and their relationships. 

Stripped arrows represent relationships between entities within each kind of model. Black arrows represent model 
cross-links. 



3.2.4. 1. The data model 



The data model describes the objects of the system, definitions, attributes and relationships. These objects are either 
concepts (abstract classes such as Patient or Clinical Request), labels used to identify instances in the abstract classes 
(e.g. Patient Name), or comments data (e.g. Clinical Criterion). 

Static constraints must also be considered, as well as criteria for association, such as aggregation, generalisation or 
specialisation. 

The data model is of prime importance in the modelling process because it is necessary to know and describe what can 
be changed or transformed before describing when and how these changes or transformations take place. 



3.2.4.2. The functional model 



The functional model portrays what the system does, without regard for how or when it is done. It is composed of two 
levels. 

The first level concerns data exchanges between the system and its environment. It is often called the context diagram. 
It is used to specify services and requests supported by the system. The context diagram delineates the frontiers 
between the system and its environment. It can serve as the basis for the definition of the relevant interfaces and the 
Application Program Interface (API). Consequently, establishing the context diagram is a fundamental step of the 
modelling process which must be performed before all other tasks. 

The second level is concerned with the internal functions of the system. It deals with transformations of data values 
within the system, and is independent of when these transformations are performed. It describes data flow between 
these transformations. 

Usually, in order to be understandable, the functional model is normally not directly expanded into simple operations, 
but into high-level functions. These functions are then broken down into smaller computational units. This top-down 
decomposition allows one to manage the complexity of the functional model, and to structure the system into loosely 
coupled understandable subsystems. 



— 32 — 



— MIMOSA Models — 



3.2.4.3. The dynamic model 

"The dynamic model describes those aspects of the system concerned with time and the sequencing of operations - 
events that mark changes, sequences of events, states that define the context for events, and the organisation of events 
and states." [Rumbaugh et al. 1991]. It describes control structures and the sequencing of operations, but is 
independent of implementation issues. Consequently, it does not define the algorithms driving the state transitions, but 
is concerned with the conditions on the system allowing a state transition to be fired or a state to be reached. 

Events are defined either by changes in system state (change in entity state or in the population of the conceptual 
base), or by external events such as service requests coming from an external user. 

3.2.5. The crosslinks between models 

Each of the above models represent a particular aspect of the system. All three models are necessary to represent the 
UoD in a complete and consistent way. Moreover, the 3 viewpoints cannot be independent. On the other hand, to 
ensure efficient modelling through a refinement process, they must be loosely coupled. It means that only a few well- 
defined and identified cross links should be necessary to synchronise the different stages of the modelling and to 
ensure its consistency. 

Below, the cross links between the models and their meaning are defined. 

3.2.5. 1. Data model vs. functional model 

In the functional model, data flows are used as inputs or outputs by functions to and from data stores. Each data flow 
corresponds to a set of entities of the data model. These sets constitute different views of the data model, or 
submodels, including tightly coupled entities (called fragments by Abiteboul and Hull [1987]). 

3.2.5.2. Functional model vs. dynamic model 

The goal of the dynamic model is to assemble and synchronise the different functions into a coherent operational 
whole. The procedures of the dynamic model are linked to the functions of the functional model. The occurrence of an 
event may correspond to changes in the data, to the completion of a procedure, or to an internal event (e.g. a timer). 

3.2.5.3. Data model vs. dynamic model 

The global system state is composed of the set of instances populating the conceptual base and of the individual state 
of each entity belonging to the system. 

State transitions, enabled when certain events hold and a certain amount of entities is available, are marked by the 
consumed entities (input data) and the produced ones (output data). These entities are related to the data model. 

3.2.6. Modelling tool 

The CASE tool ISW® (ITS, Bruxelles) used during the modelling stage of the MIMOSA project is based on the 
NIAM methodology for the data model, on data flow diagram for the functional model and on Petri nets for the 
dynmic model. A detailed presentation of the methodology underlying each model is given in Appendix 4. 



3.3. The environment 



3.3. 1. Context and interfaces 

Each medical speciality involved in the image handling has its own internal and partial viewpoint with respect to the 
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general problem of image handling within a medical institution. In order to come to a joint understanding of the 
problem, it is necessary to agree on an explicit external model of the domain [Chameroy et al. 1992, Herbst and Retter 
1988, Huang 1992, Huang and Taira 1992]. Thus, the MIMOSA topic has mainly to take into account: 

• Data involved in image handling, 

• Image handling scenarios associated with routine and research utilisation, in terms of goals and triggering events, 
from a user' s viewpoint, 

• The image life cycle in order to manage and supervise the changes and transformations they undergo, 

• Actors manipulating images: who they are, what their technical or medical responsibilities are, what their 
intentions when acting on images are. An actor is defined as an outside entity which interacts directly with the 
system [Rumbaugh 1994]. 

The image 'actors' are image sources, image users applications, image archiving systems and HIS / DISs. The 
interfaces between such actors are of different natures, and more or less easy to define. 

• The interface to the image source is fairly well defined, since most image sources are stand-alone systems. This 
interface has been the topic of extensive standardisation efforts such as DICOM and MEDICOM. 

• The image user interface is more difficult to define, since image use may correspond to image processing, 
analysis, interpretation or viewing; the interface must provide users with information needed by the task 
undertaken, while being application independent. Three main kind of users' tasks can be listed, each of them 
defining a set of specific services: 

- Services intended to allow the user to consult the image bank or data base, to select images to be displayed 
or to be processed, and to reference images for instance, from patient records. 

- Services allowing the access to the image contents, that is the actual read and write operations from user 
applications. 

- Services related to 'telematics'. They allow the circulation of digital images among the various classes of 
users, especially putting image at the user disposal and managing opinion requests. 

• The archiving system interface must allow various file format standards to be used for archiving and retrieval of 
image data to and from various image sources and user environments. This interface must translate and encode 
data between the user representation and codes supported by networks and archives. It must also supervise 
input / output operations, that is it must act as an abstract file management system. 

• The HIS / DIS interface (in a wide sense) must be able to provide image related information to the HIS / DIS, and 
to retrieve HIS / DIS data used in image management. These information can be issued from hospital, 
departmental information systems (e.g. radiological) and from act management systems. This is clearly the 
fuzziest interface since, for different implementations, images are likely to be managed using HIS / DIS systems 
having quite different functionality. It can also provide scheduling information related to image examinations: 
scheduled examination, . . . 

The MIMOSA scope can thus be summarised as shown in figure 3.3.1-1. 
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figure 3.3.1-1: The MIMOSA scope. 



3.3.2. Flows and data model 

A goal of the MIMOSA system is to include the underlying data model in a model of the medical image (in a wide 
sense) with its environment. This ensemble of information is provided at the user level, (through acquisition systems, 
and users' workstations) and includes clinical information which overlaps HIS / DIS information models (figure 3.3.2- 
1). 
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figure 3.3.2-1: User data circulation between the user world level (which includes all users' applications such as 
acquisition, processing, reporting and viewing) and the implementation level (including archiving and storage, 
networking and HIS/DIS access). 

Management of the circulation of the various kinds of user information is described by the functional model in terms 
of functions (services) and data flows. This functional model does not consider the temporal behaviour of the system, 
but the data manipulated and created by each MIMOSA functions. Most of these functions need information on the 
system configuration in order to be achieved. Tasks such as that of data availability management cannot be achieved if 
information about the system configuration is not provided. Such information is used and processed to organise data 
and image transfer between all MIMOSA components, as must be modelled by the MIMOSA data model in the so- 
called image management model (figure 3. 3. 2-2). The temporal facet of the MIMOSA system is under the 
responsibility of the dynamic model. 

3.3.3. The context diagram 

Detailed comments and graphics about the context diagram and external entities can be found in Appendix 6. 

The Acquisition entity which provides a MIMOSA system with new images as requested by the HIS / DIS Act 
Management System. As relevant historical data of a patient may be needed during the acquisition of a new 
examination, this external entity is also allowed to access these data. 

User workstations are mainly used by health care professional (HCP) to process images, interpret them and create 
reports. 

The Health Care Professional entity includes both the requesting HCP (who asks for an opinion request) and the 
consulted HCP (who answers the opinion request). This conferring procedure takes place outside the scope of the 
HIS / DIS Act Management System. As the conferring procedure is often used in daily clinical routine, it has been 
included in the MIMOSA model. 
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The Processing entity provides a MIMOSA system with processed images as asked for by the HIS / DIS Act 
Management System. The Reporting entity provides a MIMOSA system with a multi-media report as asked for by the 
HIS / DIS Act Management System. These external entities are allowed to access the images to be reported, as well as 
relevant historical data. 
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figure 3.3.2-2: Functional and dynamic models and relationships with the image management data model. 

The HIS / DIS is not considered as being a single external entity. A decision was taken to decompose it into 
subsystems each with a precise meaning with respect to its functions, such as: the Act Management System, the Data 
Administration System, the Access Rights Control System and the Clinical Data Management System. This view 
facilitates a better integration of a MIMOSA system into an evolutive environment including open, co-operative and 
functionally independent sub-systems. These subsystems identify fundamental functions within a clinical institution. 

The MIMOSA system receives information about the general context of the production and utilisation of medical 
images from the act management system (AMS). This AMS manages the life cycle of acts, starting from the definition 
of act classes, up to the scheduling, execution and validation of actual acts. It provides information about resources to 
be used (personnel, temporal and equipment). An attempt to model precisely such concepts has been undertaken by the 
ESPRIT-RICHE action [Frandji et al. 1994]. 

The data administration system provides MIMOSA with information about the system configuration, such as network 
topology, archive units, degrees of data availability, access rights and utilisation of platforms. This information allows 
the MIMOSA system to be customised according to local organisation and implementation. 

The access rights control system is seen as an external subsystem which manages the access rights to all medical 
records within the institution. Hence, it is not considered as an internal function of the MIMOSA system. The reason 
for making this choice is that access rights control is not specific to medical images and applies to medical data in 
general. 

Finally, it has been decided as appropriate to consider the MIMOSA system as the interface between the medical 
imaging systems and the clinical data management system, in order to provide integrated access to all relevant 
information. A more general and sophisticated solution will be considered in the future when harmonising the 
MIMOSA model with the work of the AIM-NUCLEUS project [Joubert and Kanoui 1993] (or another AIM project, 
focusing on the organisation of the Patient Record and the customisation of the access to be offered). 



3.4. The data model 

Detailed comments and graphics about the data model can be found in Appendix 5. 
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3.4. 1. Presentation of the three viewpoints 

The data model describes in a consistent way the entities composing the Universe of Discourse (i.e. medical image 
handling within a clinical institution, and their relationships). As previously described, these entities are related to 
contextual information (e.g. demographic or clinical data) essentially coming from administrative information systems, 
actual image data created by acquisition systems and user workstations, and management data useful for image 
distribution. Then, this universe is composed of three major loosely interrelated parts (figure 3.4.1-1). 
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figure 3.4.1-1: The MIMOSA context and its relationships with the data model. 

• The first part describes the general context of the production and utilisation of the images, it is called the 
examination context model. It defines the information entities which are primarily managed by administrative and 
departmental information systems. These examination context data are tightly coupled with clinical utilisation, e.g. in 
daily routine. However, in quality assessment task, in research or teaching they may be meaningless, and thus can be 
absent. 

• The second part describes the nature and structure of image information, called the image kernel model. This 
model allows a common understanding of the images to be shared by the various systems exchanging medical images, 
for example acquisition systems, workstations and archiving systems. Quality assessment, research and teaching 
information can be modelled at this level, for instance specifying special kinds of image collections (e.g. reference 
databases or calibration bases or quality assessment). 

• The third part describes at a conceptual level the entities which are involved in the image flow management 
process itself, called the image management model. This allows a MIMOSA system to support the relevant 
communication mechanisms and to guarantee to the users an adequate level of availability of the images. 

3.4.2. Interaction of the 3 models 



In the following, the three parts of the data model are presented separately, although they express three different and 
complementary viewpoints on medical images. Thus, few and well defined relationships between modules exist. 

The examination context module is connected with the image kernel through the various examinations or examination 
steps. The semantics of the relationship is that the resulting images, or image collections have been created during the 
related examination or examination step (figure 3.4.2-1). 

Clinical use of images is described by examination context data while other uses generally do not require such data. 

For the management and distribution, images or image collections are gathered with contextual information and 
encoded according to some representation rules into data units. These data units are physically stored in 'copies', 



— 37 — 



— MIMOSA Models — 



which are the objects concerned by the availability requests, transfer and consultation by users. 
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figure 3.4.2-1: Cross-relationships between the three modules of the data model. 
Gray lines represent the connections between parts of the data model. 



3.4.3. Type of documents 



The MIMOSA model aims at providing a general framework for the circulation of medical image related documents 
within an institution. Consequently, it must enable the correct and reliable transfer of documents to a recipient 
(including text or voice for reports or opinions, images and their associated parameters). Moreover, documents must 
be understood in the same way, even though systems in terms of software or hardware can be different. 

The standard modelling approach would be to represent these documents by a LOT (the NIAM mechanism to model a 
"black box") because their internal structure does not matter for the model. Unfortunately, the documents are often 
structured, divided into sub-documents, and they contain "meta-information" that describe structural and semantic 
relationships among sub-documents. As such, documents are not simple linear streams of characters. Thus, the LOT 
approach does not guarantee that documents can be retrieved and understood by the recipient as there exist many ways 
to encode and manage document contents. 

To overcome these drawbacks, standardised document presentation should be used: EDIFACT, ODA / ODIF [Baronas 
1992, Ghernaouti 1990] or HyTime [Goldfarb 1991, Newcomb et al. 1991] for texts, voices, reports and 
opinions / advice and DICOM for images. However, such a solution shows some shortcomings. They can provide a 
framework for presentation and interchange of documents, but not for their archiving and management. Moreover, 
many aspects specific to medical imaging are not addressed by these standards. 

In spite of these problems, it is necessary to provide a sufficient amount of information allowing the management and 
understanding of such documents. Consequently, this information has been modelled in the MIMOSA model by three 
components which are: 

- a LOT / NOLOT referring to the type of document. 

The type of the document is mandatory. This concept is not intended to provide some formatting instructions about the 
data contents (e.g. media formats or encoding). Its role is to provide a way to express how any numbers of entities, 
encoded in any notation, are gathered in some way or for any purpose. Thus, the implicit description of the logical 
architecture of the document (e.g. the division into sub-documents and their relationships) is enabled. 

- a LOT corresponding to specific parameters of the document such as elements of the syntactical architecture 
(e.g. XDR or BER, the ASN.l related encoding format) and presentation. 

This LOT may be absent. Its actual structure is out of the scope of MIMOSA. One of its roles might be to contain a 
"style sheet" or a layout which provides either a set of formatting instructions or a set of rendering information for 
human perception in space, in time, or in both space and time. It is worth noting that this information is often critical to 
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understanding the document. 

- a LOT corresponding to the encoded document as a bit-stream. 

Such a modelling matches the recommendations indicated by standards such as HyTime. "When a definition of a 
document type is created, a distinction is made between information and rendering instructions" [Newcomb et al. 
1991]. Similar conceptual architecture is used in various document filing projects (e.g. [Kirste 1993, Pozzi and 
Celentano 1993]). Indeed, as stated by Fowler [Fowler 1994], "the application view (our type of document) defines 
what information is to appear [...], not the format in which it appears. Such issues [...] should be considered part of a 
separate component: the presentation. [...] Logically separating them is important because they are essentially different 
tasks [...]. This is particularly important when different user interfaces are required for the same view; this can happen 
with varying user preferences and user-interface technology". When the components of a document and their 
relationships are relevant to tasks allotted to a MIMOSA system, a finer description of the logical architecture of the 
document must be provided. This description, which is denoted by the term "Generic View", allows the modelling of 
various kinds of image (related) collections. By this method, the mechanisms for managing and processing documents 
or document structures can be realised independently of the content interpretation. 

Such an approach assumes that all the users connected to a MIMOSA system share a common language which must be 
understood (if necessary, through a translation engine) by the users' application (or users' application classes). It is not 
within the scope of MIMOSA to determine the consistency between the user application and the encoded data, but it is 
under the responsibility of the application itself. This mechanism ensures the availability of an adequate copy of the 
document according to the types of documents supported by the user's workstation. It allows the customisation of a 
MIMOSA system with respect to its real environment. So, the generality and the versatility of the MIMOSA model are 
increased without increasing its complexity. 

Similarly, the image management module must refer to MIMOSA Directory Management (MDM) features to store and 
archive copies using official standard as DICOM or de facto standard (e.g. FTP, NFS, FTAM [Henshall and Shaw 
1990, Nussbaumer 1991]). Consequently, the MDM and its related services (e.g. copy, move, export or import) are 
described by three components: 

- a NOLOT corresponding to the real entity to be managed (the instance of directory or data management request 
description), 

- a LOT / NOLOT referring to a service type offered (e.g. NFS or UNIX-compatible file management) and, 

- an optional LOT containing some specific parameters which have a meaning for the service, but not for a 
MIMOSA system itself. They represent information about media format [ACR-NEMA 1993] or about the space 
allocation into storage spaces. 

3.4.4. The examination context model 

It has already been stressed that it is important to take into account the general way images are produced and used. 
Thus the data model must take into account many concepts which are not directly related to medical images but which 
are or may be required either by an information system (to achieve management tasks) or by the users themselves (to 
perform their application tasks). Most of this information is usually created and managed by administrative (HIS) or 
departmental information systems (such as a RIS). 

Moreover, because the MIMOSA model is unaware of the origin of data and of the system used for their management 
and control, it is still valid when such administrative or clinical data are not provided by a DIS. 

The question of whether a particular entity "belongs" to a particular system such as a PACS, HIS or DIS (in the sense 
that such a system is entirely responsible for the storage or consistency of that entity) is not addressed in the data 
model. Such issues should be treated as part of the implementation process since it is inappropriate that they are 
considered at the conceptual level. 

3.4.4. 1. Scope of the model 

The MIMOSA objective is certainly not to model all concepts involved in a DIS but to focus on those concepts which 
are more tightly related to image management or must be provided to MIMOSA users to satisfy their requirements. 
However, this approach is insufficient in order to decide whether a given concept must be modelled or not. The choice 
of concepts to be modelled was in general a trade-off taking into account several factors such as: 1) the relevance with 
respect to image management issues, 2) the type of expertise of the MIMOSA team and 3) the available resources 
within the MIMOSA topic. 

For example, modelling entities such as examination, report or clinical request seemed essential, since basic 
applications in diagnostic radiology (in particular the performance of an examination and reporting) require the 
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management of these concepts. Attributes such as examination type are also necessary to allow the management of 
examination results (for example for the creation of worklists using criteria such as modality or anatomic region). 

In a similar way, the patient entity has to be modelled and certain attributes were considered which seemed relevant 
although the general specification of a mechanism for patient identification is beyond the scope of MIMOSA. 
Concepts such as clinical context of an examination have been identified and included in the model but no attempt was 
made to model this information precisely, since such detail is more particularly the work of other AIM projects and 
standardisation bodies. 

However, image management and understanding is not limited to data, control and information flows between image 
systems and HIS / DISs. But, such tasks, although not managed by HIS / DIS, may make a usage of data managed by 
the HIS / DIS (e.g. clinical data in teaching or clinical research). For instance, tasks relevant to research or to teaching 
have not to be managed by these administrative systems. 

Likewise, health care professionals may establish communications between themselves outside a standard scenario 
such as examination request, image acquisition, image interpretation, reporting and report diffusion. Such 
communications include expert consultations and opinion / advice requests in order to help in the achievement of 
clinical image related tasks (e.g. acquisition, processing, interpretation or reporting). 

The above two classes of behaviour belong to the daily routine, although they cannot be scheduled and managed by 
administrative or departmental systems. Consequently, entities related to these tasks must be taken into account inside 
the MIMOSA model. However, with regard to the three viewpoints on image we have defined, they mainly belong to 
the examination context model. 

3.4.4.2. Main concepts 

The patient is central to all clinical tasks. It is necessary to provide MIMOSA users with all relevant characteristics of 
the patient, including those coming from the administrative and clinical systems. It is important that the patient 
identification is consistent with the HIS. 

We considered that an examination cannot be satisfactorily acquired or used unless the reason why the examination 
was performed is available to the health care professionals responsible for this acquisition or usage. These reasons are 
described by the clinical request. 

The diagnostic imaging procedure, or examination, permits gathering together the images acquired on one or several 
devices in response to a clinical request. Various steps are necessary to represent precisely the acquisition, processing 
and reporting stages of the examination. Furthermore, both a priori and a posteriori viewpoints on each steps are 
needed. Knowledge about scheduled step is necessary to allow the prefetching of previous examinations relevant in the 
given context. Description of the performed step includes the information provided by the equipment used to perform 
it. They can be forwarded to the AMS, in order to inform it about the human, temporal and material resources which 
were actually used. 

The performed examination registered within a MIMOSA system can take place within the institution (internal) or 
outside (external), i.e. within another institution. 

Sometimes, it is useful to gather examinations together which are related according to the same clinical criteria into 
what is called here: views on patient record. This provides the user with a convenient way to browse through the 
patient record and to select relevant information in a given context. 

MIMOSA provides also the users with a facility to exchange messages (opinion requests and opinions) making 
reference to images and examinations at any point connected to the MIMOSA system. 

In every case, it is necessary to identify the health care professional(s) who is (are) responsible for the generation or 
validation of the medical information (examinations, reports, addenda, opinion requests, opinions, etc.). 

3.4.5. The image kernel model 

3.4.5.1. Presentation 

The image kernel has been designed according to the following specifications: 

• Not only 2D but also ID (e.g. ECG signals), 3D (e.g. stacks of CT slices) and more generally nD data must be 
managed by the model. 

• Different points of view must be accepted on nD data without having to register them as distinct entities. For 
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instance, a dynamic tomography can be considered as a spatial stack of temporal series, or as a temporal 
sequence of volumetric data. These two views must be accepted by the model as user's view on the same entity, 
not as two distinct entities. 

• Not only scalar (e.g. grey level) but also vector (e.g. colour coded RGB) images must be managed by the model. 

• Relationships between images, resulting from the specific characteristics of the acquisition (such as positional 
relationships between images within a time series), must be managed by the model. 

• The relationships between simultaneously acquired image objects (e.g. an ECG signal and a cardiac angiogram) 
must be managed by the model. 

• The relationships between image objects, created as a result of image processing must be managed by the model. 

• User-defined relationships between image objects must be managed by the model. 

• As it is impossible to list all the image types, due both to the diversity of medical examinations and the increasing 
diversity of (new) clinical applications of medical images, the model must be open and extensible. 

The first four requirements lead naturally to the concept of an image object, which is central to the model. Hence the 
word "Image Object" (IO) will be used hereafter as an entry point to the Image Kernel rather than the word "image" 
to avoid any 2D connotation which might be misleading. 

The three next requirements lead, in particular, to the concepts of: Reference Position, Modality (which is generalised 
through the concept of Image Generator), and image object group (Generic View). 

The last requirement argues for the existence of a formal description of the nD data. 

3.4.5.2. An introductory example 

Consider a set of films corresponding to an angiogram. Assume that the data have also been digitised. A radiologist is 
likely to consider the set of films as a set of 2D images, while a computer scientist is likely to consider the data as a 
stream of bytes. Both views are too restrictive. Such data, analogue or digital, must be seen in 3D in order to make the 
temporal and spatial relationships between picture elements explicit. 

Normally, a radiologist does not consider spatial intensity variations of a single image at a time, but rather as time and 
space variations. For example, time dependency is taken into account when mask images are subtracted from contrast 
images, while space dependency is taken into account in edge enhancement. The reasons why an angiogram is often 
perceived as being a set of 2D images are: 

• it (may) exists as a set of 2D films, 

• time is sensed in a different way to space (they are not commensurate), 

• time is sampled while space is continuous in this example. 

These are inadequate reasons and are just one way (perhaps the most direct) of expressing how such data may be 
understood. Although they lead to a model perhaps well suited to very specific users' needs, this is very application 
dependent and results in a model which does not carry the 3D nature of the data. 

The MIMOSA model adopts the following strategy: 

1) If the data are really 3D, they should be handled in 3D because the MIMOSA model always considers data at 
their true dimensionality. All the potential dependencies are thus considered. This approach is application independent, 
since it allows applications to see data as required, not as the model forces them. This is called the formal aspect of the 
model. Since data here are isomorphic to a 3D function, all operations carried upon the data can be expressed in terms 
of operators acting upon a 3D function. 

2) Since time is indeed not the same thing as space, this must be expressed in the model. This can be achieved by 
specifying the nature of each variable, whose attributes are defined in the formal aspect of the model. Notice that, at 
this formal level, variables are defined, but their values are still ignored. Hence all angiograms will have the same 
formal aspects, because they correspond to functions of time and 2D space. On the contrary, angiograms and stacks of 
CT slices, while both being 3D structures, will have different formal aspects, since the former correspond to functions 
of time and 2D space, and the latter to functions of 3D space. Basic data structures are thus specified in the formal 
aspect. Notice also that the formal aspect must also define attributes to distinguish x and y variables in order to clear 
up ambiguities about the nature of variables. Two different space variables such as x and y must be distinguished in the 
same way as time and space variables are. The signal to be measured must also be specified, otherwise the formal 
aspect of an angiogram would not differ from the one of a dynamic nuclear medicine series. Finally Reference Position 
and Image Generator attributes, which will be considered later, must also be attached at the formal level. 

3) Features related to the actual data must now be considered. In this example (the analogue angiogram) time is 
sampled while space is continuous. This is not the case for all angiograms; space is also sampled for the digital 
angiogram. The formal attributes do not depend on the form of the actual data; all such angiographic data correspond 
to a function of time and 2D space. However, the IO (Image Object) version attributes do depend on the actual data 
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and depend on how the measurement was performed. The word "IO version" (version for short) comes from the usage 
that the set of films is often described as "the analogue version of the angiogram", while the byte stream resulting from 
digitisation is usually referred to as "the digital version" of the angiogram. A given image object has one and only one 
formal aspect, but may exist in several versions, as can be the case for an angiogram. More versions can be defined if 
variables are digitised in different ways. For two differently acquired angiograms, the common attributes stored in the 
formal aspect of the model will be the same, while attributes stored in the "version" will be different. This is called 
factorisation. 

4) The IO representation (representation for short) of the data must be defined. While analogue versions of 
image objects are fully specified using very few attributes, this is not the case for digital versions. As previously 
mentioned, a computer scientist considers a digital angiogram as a stream of bytes. The relationship between the 3D 
structure, and the byte stream must be specified. This is the purpose of the part of the image kernel called the 
Representation. Two types of representation are considered: conventional representations and non conventional 
representations. The conventional representation assumes that the 3D structure is scanned along each direction in an 
orderly fashion, e.g. x first, y second, t last. Non conventional representation aims at describing more complex 
scanning strategies such as those used when images are compressed. 

5) Finally, one must define how the data comprising the image object and associated data can be used to build 
the byte stream. Several copies of the byte stream may exist inside the image management system at a given time. It is 
outside the scope of MIMOSA to describe the organisation of such physical files, while this is the very purpose of the 
various image file formats such as Papyrus, Interfile etc. 

3.4.5.3. Rationale of the image kernel model 

The image objects can be considered at different levels of abstraction, which must be taken into account by the model. 
Thus, the image kernel is highly structured as it takes into account all level from the very abstract one (the image 
object) to some concrete considerations. Subsets of the image object attributes are assigned at these different levels. 
This is a key feature of the model. It is not a flat model such as those provided by most file format standards. Its 
structure expresses the relationships between various description levels of images. It is not a "yet another image file 
format standard"- it is an image model which may be implemented image file format standards. Therefore, unlike file 
formats, the MIMOSA image kernel model is independent of implementation considerations and allows a uniform 
background for image handling within a clinical environment. 

However, standard image formats such as DICOM / MEDICOM are subsumed as models under the MIMOSA image 
kernel model. As a physical format, they can be an implementation tool of the MIMOSA model. In the following text 
the term DICOM is used to mean the current DICOM / MEDICOM standard as published in 1993. 

The role of the formal description level is to allow the versatility and the expansion of the managed data types. As a 
matter of fact, every managed image object must be typed. There exists three possible strategies to do it. 

1) The DICOM Modality can be used as a label for each image object. 

Unfortunately, this concept is rather fuzzy and ambiguous. It takes its value from a list of items which portray in some 
cases the physical process only, such as X-rays, or is related to some pre-processing (e.g. tomographic reconstruction 
in SPECT) or to an organ. In this form, this modality concept is close to that of examination type, and it can overlap it. 
Moreover, it does not provide neither a uniform view on image objects, independently of the modality nor systematic 
rule of description because it is not based on a model. Therefore, it is very difficult to enlarge the set of described data 
without damaging the transportability or the generality. 

2) The DICOM Acquisition Type can label the image objects. 

This concept leads to the definition of the various modules described in the Part 3 of DICOM [ACR-NEMA 1993]. It 
presents some drawbacks from the point of view of the purpose of the MIMOSA topic. First, it does not deal with 
graphics and ROIs in the same manner as images and curves. Secondly, it only allows single curves, single 2D images 
and, for certain modalities, 3D uniformly spatially or temporally sampled images, called "multi-frame images". For 
instance, dynamic tomography (e.g. cardiac equilibrium tomography) or multi-energy dynamic acquisition (e.g. in 
Nuclear Medicine) cannot be straightforwardly described. A "folder" of images or multi-frame image must be used to 
encode each point of view on these data. For instance, one allows the representation of the dynamic tomography as a 
spatial stack of temporal series, an other as a temporal sequence of volumetric data. But, it is not easy to notify that 
these two folders denote the same entity. 

Such strategy is not appropriate to represent image types which are not described in the DICOM documents such as 
multi-echo images in MRI or parametric images. 

3) A construction-oriented approach of description can be specified to type image objects. 
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First, such an approach distinguishes the image types from its observation (version level) and allows the description of 
non uniformly sampled data. Secondly, scalar or vector images, curves, ROI, graphics and any multi-indexed 
sequences of these objects are described in a uniform manner. Thirdly, various points of view can be supported on the 
same entities, without having to register them as specific entities. These points of view will be managed by the query 
language. As example, a dynamic tomography can be defined as a function DT from the spatio-temporal space into the 
signal space as follows: 

DT:XxYxZxT^S. 
A spatial stack of temporal series is described as follows by the second order function ST: 

ST:Z^(TxXxY^S), 
and the temporal sequence of volumetric data is described by the second-order function SV: 

SV:T^(XxYxZ^S). 

It can be proved that ST and SV denote two "currified" versions of the function DT, that is ST, SV and DT are 
equivalent [Meyer 1990, Xuong 1991]. To obtain ST (respectively SV) from DT, it is sufficient to fix the Z-value 
(respectively. T-value) and to extract the temporal series (respectively, the volumetric data) for the fixed value. This 
operation can be automatically performed by the query manager engine. 

This construction-oriented process allows a monotone enlargement of the model without threatening the consistency 
and the transportability of data. Moreover, it is compatible with DICOM as DICOM can be used at the implementation 
level. This is the method proposed in the MIMOSA model. 

3.4.5.4. Main concepts 

The highest level of the model is the formal aspect level, which defines the dimensionality of the measurement space 
(variables and signal). It specifies a nD function from which all operations performed on the image object can be 
formally defined from a mathematical standpoint. It contains the mathematical aspects of the n-dimensional function 
defining the resulting object. At this level, the object is represented as a set of elements (IO elements) which are the 
variables and the components of the corresponding function. All the features which characterise the object in a general 
way are grouped at this level, independent of the different versions and representations. This level is also defined as 
being the Image Object concept. 

The attributes describing for which values of the variables the signal is actually measured are then defined at the 
version level. A version is analogue if at least one of its elements is analogue, i.e. a variable is not sampled or a 
component is not quantised. If all variables are sampled and all components are quantised, the version is digital. The 
attributes describing the way elements are digitised are also defined at the version level. Several versions can be 
attached to the same formal aspect, especially when analogue and digital versions exist, although all versions 
correspond to a single measurement process. If the same process is measured twice, two image objects with almost 
identical formal models will be produced. An image object is produced by an image generator which can be either an 
acquisition or a processing operation. 

Because ID signals are simpler to describe than nD signals, and because the image kernel aims at describing signals of 
any dimension, the example of an ECG signal may be considered. The underlying process (the cardiac electrical 
activity) can be modelled by a ID scalar function (formal level). An ECG corresponds to the acquisition of this 
process during a finite time window. It results into an analogue signal plotted on a paper strip (analogue version). It 
can also be digitised at different sampling rates (e.g. 100 Hz or 2 kHz) resulting into various digital versions. 

These different versions, in particular the digital ones, are then stored on various media using different coding 
techniques. It is therefore necessary to describe how they are actually represented. The attributes describing how a 
digital nD image object is mapped onto a byte stream are defined at the representation level. 

Finally copies of the image object correspond to the actual data physical files which can be copied, moved, etc. They 
are organised according to a file format standard which is outside the scope of MIMOSA. Several copies may exist 
within the image information system at a given time, depending on actual users' needs. For example the file held by a 
file server may also be found on a backup medium. A copy is characterised by an access strategy. It must be mentioned 
that analogue versions can also exist in single or multiple copies. 

The hierarchical structure naturally induces attribute factorisation which expresses relationships between various 
components of an image object (figure 3.4.5-1). 
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3.4.6. The storage and image management models 

3.4.6.1. Presentation 

A specific but very important aspect of the management of medical images is the capability to guarantee the timely 
availability of images to the users. Whereas this issue is generally not considered at the conceptual level in the design 
of information systems, it is a central issue in PACS. The availability of images is directly influenced by the 
characteristics of medical image transmission namely the need to work with huge volumes of data, and the need for a 
very fast access during the working sessions. 




figure 3.4.5-1 : Hierarchical abstract architecture of the MIMOSA Image Kernel 

Previous PACS experiments have highlighted how important it was to guarantee that images are available in due time 
to users when they need to access them. In the literature one type of solution to this problem is often referred to by the 
notions of prefetching and preloading. The classical way to deal with this problem consists of defining a hierarchy of 
storage levels with a short term, medium term and long term archives, based on different technologies characterised by 
different access times, storage capacities and costs. Nevertheless, these concepts are generally discussed independently 
of each other, i.e. no particular efforts exist to address them in the unified way. Moreover, from an organisational 
viewpoint, these concepts usually mix what is general with what is site-specific. Finally, their implementation is bound 
to the physical devices supporting storage and communication. 

In MIMOSA this need has been addressed in a slightly different way, in order to cope with the concern for remaining 
independent of implementation issues. The concept of the level of availability of a set of information with respect to a 
user has been defined. This availability level characterises the time it will require to transmit a set of data stored in a 
storage area (indicated by the concept of MIMOSA directory) to the Consultation platform used by the MIMOSA user. 
This is the guaranteed response time, not the time actually taken for the transmission, and is defined in a macroscopic 
way, for example: 

- level 1 : immediately available (order of a few seconds) 

- level 2: available (order of a few minutes) 

- level 3: not available (order of a few hours) 

The definition of these levels has to be specified by the system manager and takes into account local functional, 
organisational or implementation specifics. 

It must be stressed that these considerations are independent of implementation, which is one of the major features of 
MIMOSA, such that many ways of managing the images in digital or analogue form (film), or even both within the 
same system, are possible. 
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3.4.6.2. Rationale 

Actually, it appears that the utilisation of medical information in general, and medical images in particular, is closely 
related to the different activities within the hospital. Most of these activities are scheduled or can be anticipated, 
except those encountered in emergency situations. Therefore, much moving of data can be planned for a (relatively) 
long time ahead. 

As stressed above, this physical image management can be analysed at different level. At the macroscopic level, it can 
be described by a set of largely agreed concepts, whose precise meaning is 'modified' by local environment. This level 
is proposed to manage prefetching, preloading and layered archives in a generic, deterministic and implementation 
independent way. It defines no rules of prefetching, preloading or archive-level migration because these rules are 
highly site-specific. This level can also be used as an input level used by tools for "intelligent management" of network 
based on actual throughputs and loads. 

The existence of this macroscopic level of description is crucial to guarantee the flexibility and the evolution of the 
PACS with regard to the possible physical implementation, in terms of both hardware and software. 

The generic nature arises from the fact that the basic mechanisms required to place data at the user's disposal are 
always the same. They consist of moving or copying data between different storage areas, in order to offer to the user a 
more suitable level of availability (i.e., either a faster access - if such a fast access is necessary - or a slower one - if the 
request becomes less constraining). 

These processes can be managed in a deterministic way when the configuration is described in a semi-quantitative 
way, that is when description only focuses on order of magnitude and not in precise, quantitative performances. Such a 
description offers a macroscopic view of the system. 

From a functional viewpoint, it does not matter to the user whether the data are stored on the workstation hard disk or 
retrieved in real time from the central archive through a high speed network, as long as the access time is roughly the 
same. Consequently, equivalent services in terms of data availability can be implemented in many different ways. It is 
therefore particularly relevant to model and implement general mechanisms for the management of availability, 
allowing the system to be (to a great extent) independent of the physical components actually used. 

3.4.6.3. A generic scenario 

Upon a request issued by a MIMOSA user and parsed by the MIMOSA system itself, a certain image has to be placed 
at a certain availability level for a user. The MIMOSA system proceeds as follows: 

• It determines the platform(s) that are likely to be used by this MIMOSA user. 

• For each platform found, MIMOSA determines the directories offering the requested availability level. 

• It checks whether a copy of the requested image exists within the corresponding directory. 

• If no copy currently exists, MIMOSA determines the "most appropriate" source directory and activates the 
transfer. 

• Once the new copy created, the reference to this new copy in the MIMOSA system memory is stored. 

3.4.6.4. Main concepts 

The central concept of the image management module is the concept of availability level. It allows (figure 3.4.6-1) a 
semi-quantitative description, in a macroscopic but deterministic way, of the degree of availability of the requested 
data (image objects) for one or several PACS users (i.e., actors manipulating biomedical images). That is, it denotes a 
concept of access time between an user's workstation used for processing, display, interpretation or reporting, and the 
directory where data are stored. It also roughly precise transfer time between directory for planning image transfer. 
The precise semantics is site-dependent. 

The availability request is the query which expresses constraints on data availability and may trigger data movement. It 
stipulates the data concerned, the user(s) which should benefit of these data, the availability level required and the 
period of time during which this availability must be guaranteed. The availability request generation is transparent to 
the user. It is done according to configuration rules defined by the system administration module who is in charge of 
maintaining a general coherence between the requests and the resources available, in terms of network throughput and 
load, and storage space. 

Export requests and import requests specify data movements between the MIMOSA system and external storage areas, 
such as local hard disk of user's workstations. 

Managing data availability means that new copies of existing data, known by the MIMOSA system, may have to be 
created in appropriate storage areas. Since the image management system is supposed to guarantee this availability, it 
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has to monitor a number a storage areas where data cannot be written or removed outside its control. Such storage 
areas are called MIMOSA directories. 

This notion of Copy refers to the physical object(s) (e.g. file or group of files) containing a particular Image Object. 
Actually, although availability management could be applied to both image and non-image data (since it manipulates 
copies without knowing the actual content of them), it was decided to limit this operation to image data. There are two 
major reasons for this choice: 

• First, the image management model is primarily addressing the problem of image data, because the high volumes 
involved absolutely require availability management. 

• The second reason is related to the potential complexity of the relationship between the entities (considered at a 
conceptual level) and the physical objects containing them. Actually, availability management could be applied to 
non-image data, such as vocal or textual reports (including multi-media reports) or more generally to complex 
aggregates such as Views on Patient Record. 



Description of Image Servers (image bases or banks) 



Image Management Model 



MIMOSA directory 




MIMOSA workstation 


MIMOSA user 



[1,1] Availability Level 



User description 



Concept of session (login) 



[l,n] 




Description of workstation (e.g., acquisition, processing, display, interpretation, reporting) 



figure 3.4.6-1: Main concepts of the image management module and their relationships. 



In the latter case, the system must be able to manage the links between the users' views and requests (browsing, 
selection of entities such as images, reports or views on patient records) and the physical objects actually transmitted 
to them. Moreover, the system should be able to select and build (if necessary) the appropriate physical objects to 
export them to a requesting user, or put them in the appropriate MIMOSA directories, according to eventual 
availability requests. It appeared to the MIMOSA topic group that the modelling of such mechanisms were of too 
complex of a nature to be properly modelled in the framework of the project. 



3.5. The functional model 



Detailed comments and graphics about the functional model can be found in Appendix 6. 

3.5.1. Presentation 



An aim of MIMOSA model is to model the management of medical images, and its related information and 
documents, in a generic way. It means that the proposed model has to be applicable in any discipline producing or 
making use of medical images, and not only for radiologists. Consequently, the MIMOSA model covers a wide 
spectrum of functions to assist the production or the use of medical images. Major functions described in the WP 2 
document were identified as being: 

- Offering an access to existing patient folders, 



— 46 — 



— MIMOSA Models — 



- Supporting the execution of image-related acts, 

- Supporting communication and image data exchange between users, 

- Allowing the access and selection of medical images for different activities (diagnosis, therapy, teaching, 
research, quality assurance), and, 

- Guaranteeing data availability to users. 

The MIMOSA functional model is intended to describe all the data flows and transformations involved in the 
achievement of these facilities, to provide the functions used by a MIMOSA system. 

To model this set of functions, those 'actors' who interact with the MIMOSA system have, first, been identified and 
specified. Then, for each actor and its related activity, the corresponding set of input and output data has been defined. 
This allows the system to support each of these activities. For example, before the acquisition of new images takes 
place, relevant historical images should be transferred to the acquisition station. These 'activities', which may be 
bound with logical entities, which represent the set of the so-called external entities in the functional model. They 
correspond either to clinical activities (e.g. acquisition or reporting) or administrative / management activities in the 
clinical sense (e.g. HIS / DIS activities) or in the system management sense (e.g. various kind of administrative tasks: 
configuration, access rights, etc.). The MIMOSA system exchanges data with these external entities. Note that several 
external entities can be implemented on the same physical platform. 

The data flows between a MIMOSA system and these external entities are used to define communication libraries and 
services to be used by the client applications of a MIMOSA system. Thus, the context diagram can be shown as part of 
the functional model because it represents the global system as a whole, processing data from and delivering data to 
the users as external entities. This diagram also represents the complete MIMOSA system, together with all the 
external entities connected to it. Therefore, it allows one to delineate what is within the scope of the MIMOSA 
modelling and what is outside, as explained in the paragraph 3.3. It lists those concepts and functions which are 
relevant to medical image management, archiving and communication, but does not define which are to be physically 
implemented as components of PACS or HIS or DIS. 

Once the context has been defined, the second part of the model shows how the system is decomposed into collections 
of internal functions in order to achieve all the services requested by the external entities. 

3.5.2. The functional model structure 



All user oriented tasks (acquisition, processing, reporting and opinion request / answer) share a common general 
framework composed of three stages (figure 3.5.2-1). 
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figure 3.5.2-1: General framework for user task performance. 

• Act preparation. Each imaging act is performed after a request has been sent by the HIS / DIS Act 

Management System. The reception of such a request induces responses from MIMOSA, such as prefetching historical 
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data, preloading newly generated data, informing the MIMOSA user responsible for the act, etc. 

Activity starts when an image related act has been requested and scheduled by the Act Management System 
(AMS). The request is transmitted to the MIMOSA system. According to the RICHE model of medical acts, the 
request includes items belonging to the "Act Header" (e.g. patient identification, act to be performed) and to the "Act 
Professional Contents" (e.g. clinical context). It also may refer to previous relevant examinations. 

• Act performance. The performance of an act is not the responsibility of the MIMOSA system, but of an 
external entity dedicated to achieve such a task. While the act is being performing, the MIMOSA system allows the 
user to access whatever clinical data and previous examination results as desired. 

After having selected the act to perform in the worklists, the clinician may consult information referred to in the 
corresponding request. Unlike clinical data requests, which are transmitted to the dedicated external subsystem, image 
requests are processed in their entirety by the MIMOSA system. Note that image requests also relate to information 
about examinations such as reports. These requests may indicate relevant examinations referred to in the act request, or 
examinations chosen by the performer during the act performance. 

• Act completion. After the user has performed the act, MIMOSA receives the results, and then informs the 
HIS / DIS Act Management System. Here, the main functions provided are to permit the AMS to initiate the next step 
of an examination procedure (e.g. processing, report writing, report validation) and to inform the system that new 
medical information has been produced in order to keep the patient record consistent. The 'produced image 
management function' may also trigger preloading by making an availability request with respect to the images 
produced at the location where they will be used next. Note that "to request availability" has a different meaning than 
"to allow access to": for example the access authorisation might be given by the Access Rights Management 
subsystem only after it has recorded that the examination has been reported. 

Note that most parts of the functional model involve the Access Rights checking and the Data Availability 
Management function which guarantee the availability of the data. The former task is performed by an external entity 
belonging to the administrative systems because access rules depend in general on local organisation. 

3.5.3. Main concepts 

A MIMOSA system has to cope with two types of function. 

The first type of function is user-oriented and is related to exchanges with external entities except those dedicated to 
system administration (e.g. Access Rights Management, Data Administration), to archiving or storage and to 
MIMOSA / DIS interchanges. These functions have to manage user data and user dialogues. They indicate the 
relationships of the interface of the MIMOSA model to the user world / user applications. Examples are: Opinion 
Requests and Answers, Data Selection, Reference and Consultation, etc. They obey the general framework presented 
above. 

The opinion request procedure is not limited to a single MIMOSA system. The functional model is also applicable to 
depict functions and data flows occurring during a remote opinion request scenario. 

Printing (reproduction) and digitising are also scheduled and managed by this class of functions. 

The second type of function is oriented toward data circulation, transfer and management. Most of these functions are 
internal and have to deal with scheduling information and the image management model. They possibly exchange 
information with external entities dedicated to data administration, archive and MIMOSA / DIS exchanges (especially 
when this information is associated with act scheduling). 

3.5.3. 1. User-oriented functions 

The first class of user function is related to medical acts and performance of clinical examinations such as: acquisition, 
processing, interpretation and reporting. In MIMOSA, an act is not known until it has been accepted and scheduled by 
a system such as an Act Management System (to manage the life-cycle of the examinations) and other administrative 
and clinical information (e.g. demographic, lab data). This approach allows the generalisation of interactions between 
PACS and administrative information systems. Once the act performed, the MIMOSA system delivers to these systems 
statistical data about performed operations. 

The different stages of creation, transcription and validation of a radiological report (or addendum) are not detailed in 
the functional model. Models such as the Marburg model or the DICOM / MEDICOM model describe this process in 
more details than MIMOSA does. For example DICOM details the following steps for an interpretation (report or 
amendment to a report): 
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- the recording of the interpretation, 

- the transcription of a vocal interpretation into a textual one, and 

- the approval of the interpretation. 

In fact, it was felt that this general schema was subject to a great variability, depending on the organisations, for 
instance: 

- in emergency situations, it is common that the radiologist directly enters a textual report (since there are no 
secretaries to transcribe a vocal interpretation in due time), 

- in emergency situations, the approval is entered together with the text of the interpretation, 

- amendments are generally entered directly in textual form and immediately approved. 

It seemed to be inappropriate to complicate the functional model with the details of these steps, since they are not 
general enough. Information about the form (vocal or textual) and status of a report or an addendum (approved vs. non 
approved) should be contained in a multi-media report flow. 

This class of function also includes the creation of data transfer between a user platform and a MIMOSA system 
(import and export requests). 

The present release of the functional model does not address operations related to quality assessment. In fact this issue 
had been raised very early in the project. It was considered that this issue embraces in fact two aspects: 

- Firstly, the verification of image quality prior to the interpretation of images. 

- Secondly, the calibration of imaging equipment; calibration involves more or less complex procedures 
consisting in acquiring specific calibration data (e.g. on phantoms), and checking prior any acquisition of data on 
patients, that the machine has properly been calibrated. 

Regarding the first aspect, it was considered that the verification of image quality was closely related to the acquisition 
process itself. Actually, in many situations it is difficult to define a borderline between image quality and medical 
relevance. So it seemed preferable to consider that quality verification was part of the acquisition process. 
Consequently, it was decided that the functional model should not enter in the details of the acquisition and it is 
assumed that all data entered into the MIMOSA system have been checked in terms of quality control. This attitude is 
consistent with the general scope of MIMOSA which considers the acquisition process itself outside the scope of the 
model. 

The second aspect is important, and an Image Management System should certainly include the management of 
calibration data, but it would have required in-depth analysis of a wide range of protocols and calibration procedures 
associated to acquisition, processing and reporting sessions, which was not feasible in the context of the project. 

The second class of function includes those functions which can be performed without any interaction being required 
with administrative systems. They are related on the one hand to image quality assessment, teaching and research, and 
on the other hand to opinion and advice requests and answers. They necessitate managing both images related to 
clinical acts (and possibly accessible by all classes of users, depending on their access rights) and also local (private) 
images pertinent to the request. Private images are either patient and non patient image objects attached to a Message. 
Thus, they differ from other images not by nature, but by access strategy. Consequently, they are managed by a 
dedicated function. Private images are only known about by the people involved in the request because they can only 
be consulted by the sender and the addressee of the associated request or opinion. They may be transient, and exist 
only as long as the request and / or its answer exists within the system, because their role is to provide information or 
explanations about the request or its answer. However, the clinician may wish to insert some of these private images as 
additional images of the patient record. 

3.5.3.2. Internal management-oriented functions 

The internal functions are centred about the concept of Data Availability. 

The Data Availability copes with the management of the MIMOSA system memory in order to ensure that the 
requested exams data will be available where and when needed. This concept leads to define a set of functions 
responsible for creating and moving copies upon requests arising from inside (data availability requests) and outside 
(import and export requests) the system, in order to perform preloading or prefetching. Here the term memory refers to 
the media (films, floppies, cards...) and to the set of storage locations used to store images (hard disks, clinician's 
desk, film archive...). 

Related functions determine which directories are the most appropriate to satisfy the pending requests using the data 
modelled in the image management module (relative throughputs between pairs of MIMOSA, and between platforms 
and MIMOSA directories) in collaboration with the external entities dedicated to system administration tasks (e.g. 
physical PACS configuration, Access Rights Management). The strategy to be used can be defined by means of rules. 
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The functions described in the MIMOSA functional model are generic. Nevertheless, they have to use site-specific 
information, such as information about the physical configuration (in terms of platforms, MIMOSA directories, etc.). 
Moreover, availability management involves the application of site-specific rules, tailored to specific needs 
encountered at the particular site, for example rules of generation of availability requests or characteristics of 
availability requests in terms of duration, availability level, etc. Thus, the definition and updating of this information 
falls outside the scope of MIMOSA and is under the responsibility of the system administrator. 

In addition, Data Availability Management is also in charge to the management of the storage space available in 
MIMOSA directories, including the deletion or migration of no longer useful copies. 



3.6. The dynamic model 

Detailed comments and graphics about the dynamic model can be found in Appendix 7. 

3.6.1. Presentation 

The dynamic model describes those aspects of the system concerned with time and the sequencing of operations. Its 
goal is to assemble and synchronise the functions of the functional model into a coherent, operational whole. It does 
not as such contain actual implementation details. For example, the functional model defines an opinion request 
management function, and what can happen using it. In addition, the private image management function is also 
defined, but no relationship, logical or temporal, between these two functions has been specified. The role of the 
dynamic model is to specify, in the example given, that firstly an opinion request is created, then private images may 
be entered and that, when all related images have been entered, the opinion request may be sent to the addressee. The 
functional model also assumes ideal circumstances, that is where everything works smoothly and correctly. The 
dynamic model takes real life usage into account, where abnormal, exceptional or illegal events can occur, and defines 
what to do in these situations. It is also concerned with the availability of all necessary data. 

The dynamic modelling technique offered by the modelling tool used in the MIMOSA topic is based on Petri-Nets, 
and strongly resembles the MERISE dynamic modelling technique. 

3. 6.2. Model design 

A function in the functional model is an activity which involves a set of resources (e.g., data, processors, data stores) 
whose purpose is transforming data according to an environment and a goal. No information about the resources that 
are used is provided, neither about when nor how. To be actually performed, the function must be broken up into real 
operations. The operations of the system are modelled by means of procedures. Procedures do not necessarily 
represent only operations on the database (such as write, read, delete or update), but may also be used to represent 
other operations such as computations. Note that the term database refers to the MIMOSA memory and may not 
necessarily be implemented in terms of a Data Base Management System (DBMS), but in terms of memory buffers, 
mailboxes, etc. Internal specification of the procedure (its operational behaviour) is not described at this level. 

Procedures are activated by events. Internal and external events are distinguished The former are used to indicate that 
something has happened inside the system, the later in its environment. When an event occurs, a token representing the 
event is added to the corresponding node that acts as an event counter. 

The events that may contribute to the activation of a procedure are connected to the procedure. In order to be able to 
specify which actual combinations of events may activate a procedure, some synchronisation is specified as a 
procedure precondition. Synchronisation is composed of a Boolean expression with respect to the events that are 
connected to the procedure. The procedure is activated as soon as the Boolean expression becomes true. Once the 
procedure is activated, the tokens at the event nodes that contributed to the activation are consumed (deleted). This 
means that the number of tokens at each of these event nodes is reduced by one (unless another number has been 
specified). For example, the synchronisation of the procedure 'Parse Import Request' contains the Boolean expression 
b OR (a AND c), indicating that the procedure becomes active if the event node 'Arrival Import Request' (event b) 
contains a token, OR if the event nodes 'Import processing pending' (event a) AND 'Arrival result of import' (event c) 
both contain tokens. 

A procedure always results in the generation of at least one event. For example, 'Import accepted' is an event node 
that may occur after activating the procedure 'Parse Import Request' . The production of tokens by a procedure may be 
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further refined by specifying creation rules. These rules can also refer to the data used by the procedure itself. For 
example, the rule for putting a token in the node Import accepted is: 

- an import request has been received AND, 

- the import request is consistent with the related database entities. 

Since events are usually generated by changes in data states, a procedure generally uses and produces data. Three 
types of data are to be distinguished: 

- External data are data communicated between the system and its environment, 

- Internal data are data entered into or read from the system's database, 

- Local data are data representing intermediate results not stored in the system's database. These data can be required 
for sequencing purpose. 

For example, the procedure 'Parse Import Request' receives an external data flow 'Import Request'. It puts into the 
database an 'Import Request' (Internal data flow). Once the Import is actually performed, the procedure creates a 
'Copy in the database' (Internal flow) and sends a 'Response to import request' to the external entity which requested 
the import (External flow). 

3.6.3. Main concepts 

The main concepts of the dynamic model are in general the same as the main concepts involved in the functional 
model, except they are considered from the operational point of view. 

3.6.3. 1. User oriented procedures 

As indicated in the functional model, two types of user oriented functions exist, both of which are covered by the 
dynamic model, being: 

Act oriented functions. These are mainly related to the Act Preparation which receives requests from the 
HIS / DIS Act Management System (AMS), the reserving an examination step mechanism and the HIS information 
availability. The reserving procedure ensures that two users do not perform the same task twice. This last procedure 
informs the HIS Act Management System about the completion of an act (such as an acquisition) or the arrival of 
additional images. 

Dialogue oriented functions. These are centred around the conferring concept. In such a procedure, it is 
assumed that the opinion requests (or opinions) refer to all the relevant images, both private and non-private. No 
assumption is made about the order in which the opinion requests (or opinions) and the private images arrive. 
However, if an opinion (request) refers to private images, these must be already entered into the database. 

The query procedure is a mechanism not only related to the function 'Data Consultation' (during the various 
examination step performance or opinion requests / opinion dialogue), but also to the Preparation functions, such as 
'Acquisition Preparation' . Indeed, an application may ask MIMOSA to send a worklist containing the references to the 
examinations to be performed by a particular radiologist or on a particular acquisition platform. For instance, the 
references to the data contained in the acquisition request are not automatically forwarded to the acquisition platforms 
referred to in the request. Instead, these data are written to the database and each external acquisition application has 
to query the MIMOSA system with respect to these data. 

3.6.3.2. Management-oriented procedures 

These procedures cover low-level procedures, which are often close to the implementation. They are centred on three 
concepts: data availability, import and export. Note that creating efficient achievement of the user-oriented procedures 
is based on the performance of management-oriented procedures. The MIMOSA dynamic model only considers the 
generic mechanisms underlying these procedures, and does not address them in detail. Indeed, such details involve 
site-specific rules and considerations. 

Data availability management consists in placing the image copies in the appropriate storage areas in order to manage 
the access time to images in a deterministic way. The related mechanisms make use of the description of the physical 
configuration (managed by the system administrator) and guarantee optimal utilisation of the communication and 
storage resources of the system. Availability management embraces two basic mechanisms. The first aims at 
processing new availability requests to satisfy relevant constraints, for instance the expected rapidity of access or 
security level. The second mechanism aims at processing expired availability requests. 
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Image Object Import applies to image objects created during an acquisition step or a processing step, as well as to 
additional or digitised images and the opinion request mechanism (e.g. importing private images). The actual Import is 
achieved by requiring the external platform to send the image object to the selected MIMOSA directory; although this 
operation is considered to be performed outside the MIMOSA system. 

Export applies to the preparation required for act management as well as to the opinion request mechanism (for patient 
image objects and for private images). Once the validity of the request has been verified, the actual Export takes 
places. The actual Export is achieved by requiring the selected MIMOSA directory manager to send the image object 
copy to the external platform which may be different from the one requesting the Export. This operation (the image 
object transfer) is also considered to be performed outside the MIMOSA system. 

Translations between the external format and the internal format of the MIMOSA system is provided by an interface, 
which is assumed to possess sufficient information to understand both formats and to be able to match them. 

3. 7. Tests and refinements of the 
model 

The modelling task have been started using the initial review (WP 2). Then, the MIMOSA model was recursively 
refined mainly by using consistency checking procedures provided by the CASE tool, and amendments and new inputs 
issued from the experts involved in the MIMOSA topic, and their contacts. 

The relevance of the concepts and functions elicited in the MIMOSA model were tested against actual clinical cases 
collated by the clinicians. Main results concerning this comparison are presented in the appendix 8 "Clinical cases". 
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— Standards assessment and architecture — 



Section 41. introduces the work related to standards. Section 4.2 presents a review of applicable standards, section 4.3 
presents the major features of the proposed architecture, and highlights a number of key arguments in favour of it. 



4. 1 . General issues 



MIMOSA aims at providing a framework for image management in a heterogeneous medical information processing 
environment. It is designed to be application and implementation independent and to provide its services to a variety 
of users. With respect to MIMOSA'S position within general HIS implementations, a MIMOSA system must be able to 
cooperate with components of other information systems, namely image sources producing images, workstations used 
by clinicians, storage systems, and various components of administrative systems (such as Act Management Systems, 
the Access Rights Management System or the Clinical Data Management System). Since no manufacturer is currently 
able to provide a complete (universal) system, it is essential that the interfaces between the different applications 
implementing the information processing functions are clearly defined. The MIMOSA model is a first and necessary 
step toward the definition of these interfaces, but they are not sufficient. Indeed, in addition to the definition of the 
information processing functions, and the definition of the exchanged data, it is also necessary to define: 

• How the overall system is decomposed into co-operating sub-systems. In particular the way that functional 
entities are mapped (aggregated, or eventually decomposed) into sub-systems has to be defined. 

• How the sub-systems actually intemperate. In particular, the messages exchanged and the protocols used have to 
be defined. 

The first aspect relates to architectural issues, whereas the second relates more to eventual conformance with existing 
standards. 

Whereas, theoretically, these two aspects are well separated, and could be addressed independently, in reality, this is 
not necessarily the case. In practice, the definition of an appropriate architecture for an implementation results from 
the consideration of many factors: 

1) The different kinds of data managed may impose constraints. Data having different characteristics in terms of size 
or structure may impose specific implementation requirements on the functions defined for manipulating or processing 
them. For example, manipulation of images introduces important volumes of data, requiring appropriate hardware. For 
example, in the Data Consultation function implementation, different sub-systems are involved: one moving image 
data between two storage areas, and another one providing the user with a browsing mechanism. 

2) Organisation in sub-systems may also be influenced by the sharing of data. Functions or subfunctions accessing a 
common set of data may be gathered in the same sub-system, or even the same hardware platform. It is important to 
minimise the exchange of data within the overall system, because it is generally time consuming and thus degrades 
performance. Additional mechanisms may be required in order to ensure the consistency of information, especially if 
reused several times by a sub-system over a certain period of time. 

3) Security issues may also be involved. In particular, extensive decomposition into sub-systems implemented on 
different platforms increases the risk of malfunctions (due to a failure of the platforms or communication systems 
involved). In particular, a compromise has to be found between two contradictory objectives: normalisation and 
operational flexibility. 

Normalisation is a general method used in the design of a system, used to refer to shared data rather than duplicate 
them. It has been defined in a very formal way in database theory. A normalised system (or database) guarantees non- 
duplication of the data, and thus facilitates the update and the management of consistency of information. On the other 
hand, access to data may be very complex, and involve many sub-systems with potentially poor results in terms of 
security and performance. 

On the other hand, operational flexibility is an objective which tries to ensure that the system offers sufficient 
modularity and flexibility to allow each sub-system to operate with minimal interactions with respect to the others, 
decreasing the sensitivity of the system and decreasing the liability to eventual failures. In particular, in the case of 
failure, degraded functioning becomes possible, at least during a certain period of time. 

A question often asked is as to whether the (radiological) reports should be managed by the RIS, an Image 
Management system or both. The same question could be asked with respect to worklists. This is a related issue. 

4) Performance issues also have to be considered, as previously stressed, splitting the execution of a given set of 
related functions over several sub-systems generally leads to a decrease in the performance of a system. 

5) The existence of standards can influence the architecture of the system. The definition of a standard results from a 
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long and in depth analysis of the interworking of components of an information system or systems, in order to satisfy 
certain requirements within a particular application field. The definition of the parties communicating, the underlying 
information model, the scenarios addressed by the standard, and the messages and protocols themselves, result from an 
extensive discussion between specialists in the corresponding application fields (from both the worlds of end-users and 
providers). Normally, standards, if they are any good, should be relevant in a wide range of situations within the 
general scope of the standard. Thus, a decomposition into sub-systems (communicating parties) is likely to be relevant. 
In this sense, the existence of standards can influence, to a certain extent, the definition of the architecture of the 
system. 

6) Last but not least, the existence of market-driven products creates an implicit but very strong influence on the 
choice of architecture. Indeed, the definition of the architecture must take into account existing components available 
in the market place. For example, image management systems include, necessarily, image storage systems which are 
likely to be purchased from companies specialised in that area. Whether a 'native' interface is appropriate in a specific 
domain must be studied case by case. It is clear that identifying a large data storage system as a necessary building 
block in the system architecture is certainly required with respect to cost-effectiveness. 

The general methodology used in the WP 4 Workpackage (Standards assessment and architecture) was the following: 

1) Existing standards (either published or in development) applicable for the implementation of the MIMOSA 
system were reviewed; 

2) The most appropriate standards were analysed in detail, in order to determine their degree of consistency with the 
MIMOSA model, as well as the impact of these standards on the choice of architecture; 

3) An architecture was proposed, taking into account those standards, as well as the other constraints; 

4) Feedback was provided for the modelling task. Indeed, the MIMOSA model primarily reflects a user view, 
regardless of implementation constraints. It is clear that successful and cost-effective implementation must take 
into account many other parameters, while ensuring that user requirements are still fulfilled. This feedback turned 
out to be more important than expected, which led to modifications and refinements of the model (in particular 
the data and dynamic models). 

5) Finally, feedback was provided to standardisation bodies. Standards such as DICOM, MEDICOM or IPI are 
"young" standards, which can still be improved and extended. For instance new object attributes, new 
information objects or even new service classes may be defined in standards like DICOM / MEDICOM 
(provided that the standard parent bodies consider them as useful and consistent with their standard). Application 
profiles may also be defined to simplify and make more explicit how the standard might be used in a particular 
context (e.g. for the representation of pixel data within a general standard such as IPI / IIF). 



4.2. Applicable standards review 



4.2. 1. How standards are created? 

Various communities are concerned by the technical and economical impact of standards in the field of Information 
Processing in general, and in medical informatics in particular. These include: end-users, manufacturers, health care 
organisations, researchers, etc. Consequently initiatives for developing standards may be initiated by various kinds of 
organisations such as: user groups, manufacturer associations, governmental institutions, although, officially, standards 
can only be created by an official standardisation body such as ISO, CEN and ANSI. Whatever the origin of the 
standards, they are established in general for use by a number of different organisations. The commitment to such a 
standard may be of different nature, ranging from a full consensus obtained through negotiation under the auspices of a 
standardisation body (an official standard such as IPI), to a 'de-facto' commitment which may result from the very 
important diffusion of a product (a 'de-facto' standard such as TCP / IP). 

In principle, as stated, only an internationally recognised standardisation body can make standards. ISO, the 
International Standards Organisation is one such, CEN is the European standardisation body, depending on the 
National Standards Bodies of the member countries, such as DIN, BSI and AFNOR, in another. ANSI is the US body. 
There is an equivalent Japanese body as well as many other relevant organisations such as EWOS, MEDIX, etc. The 
general mechanism used is that after a standard is proposed, it is voted open by the 'constituency' and then officially 
accepted, rejected, or modified and resubmitted. Those standards then become 'official' standards. 

A second category of standards, without the same official legal status, emanate from professional organisations such as 
the IEEE, NEMA etc. These 'pseudo' standards have been developed by interest groups that represent users or 
companies because of the general interest of those groups in providing guidelines which help common developments. 
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A third category of 'de facto' standards are developed by private companies. Examples are Postscript (Adobe) and 
TIFF (Aldus). Those products are in such a widespread use that they have been adopted by third parties and can be 
considered as 'de facto' standards. 

Standards have at present little official force; they are recommendations. The most important attribute of a standard 
('official', 'pseudo' or 'de-facto') is probably that it is widely accepted, used, and functional. In this section the use of 
the term 'standard' will therefore be used in the loose sense: any proposal which is accepted by some 'constituency' 
and which is relevant to MIMOSA. 

4.2.2. Relation to MIMOSA 

Some 'standards' are very general with respect to their domain of application (the ISO / OSI stack, IPI, TCP / IP, etc.), 
some are more specific (DICOM, MEDICOM, Papyrus, Interfile, etc.). The former do not directly influence the 
MIMOSA modelling process in that they do not contain a model relevant to medical imaging, but become important as 
implementation is undertaken. The latter group may influence the modelling as they often include a number of relevant 
ideas such as data dictionaries and functions and indeed models, which are directly within the scope of the MIMOSA 
topic. Vice-versa, the results achieved in MIMOSA can influence some of the more specific standards. Indeed, these 
standards were not frozen at the time of the development of the MIMOSA model and several members of the 
MIMOSA topic group have close connections with or are members of the committees that define these standard 
proposals (CEN, DICOM, Papyrus, Interfile). 

At the start of (and during) the MIMOSA project, two major methods could have been followed: 

• An existing standard could be taken as a 'base' standard, ensuring that MIMOSA always remained "compatible", 
or 

• MIMOSA could have been developed, independent of all such standards and, afterwards a check performed to 
see whether such standards could be supported. 

Both methods have their advantages and disadvantages. Some reasons to follow the first method are that compatibility 
with the existing standard(s) is guaranteed with the ability to use and incorporate work already completed elsewhere 
(such as the data dictionary and certain functions). Some reasons to follow the second method are that one can remain 
independent of what other worker have conceived, concentrating on real user requirements, and not having to follow 
drafts of standards that are still in a state of flux. When the MIMOSA topic was started, no satisfactory general 
standard in the medical imaging area was available. ACR-NEMA V2.0 was considered to be very limited with respect 
to the requirements addressed in MIMOSA. 

In practice a combination of both approaches was used. During the development of the model, the existing standards 
were always checked to make sure no important data elements or functions were omitted. Nevertheless, these standards 
were not considered to be complete definition for the data and functions required. These standards appeared to have 
rather poorly defined underlying models. Whenever a conflict was found between the approach indicated by such 
standards and that suggested within MIMOSA, it was decided to let the users' requirements prevail. 

There are several reasons for following this approach: 

• None of the standards considered was frozen at the time, and the likelihood of change occurring was high. 

• The possibility of influencing these standards, still currently being developed, was considerable. It was decided 
that MIMOSA should try to influence their development as it is believed that the MIMOSA point of view is 
important and pertinent. 

• This method avoids time wasting, and 'reinventing the wheel', within MIMOSA. 

• As stated previously, several members of the MIMOSA topic group are also members of the committees that 
define these standards, which should facilitate the influence of MIMOSA. 

4.2.3. Data Formats 



4.2.3. 1. Existing formats for graphical or pictorial information 

Many formats exist for storing graphical and image information. This is partly due to historical reasons (e.g. lack of 
tools), commercial reasons (every company ended up creating its own proprietary formats, e.g. Gamma-11), and also 
to (opportunistic) ad-hoc approaches (the creation of a locally designed format to fulfil a particular need efficiently, 
e.g. ANALYZE) or to favour specific structuring in the data (e.g. bitmap fax format, vector oriented plotfiles or PICT 
files consisting of graphical primitives). Only in the last few years have efforts been made to define 'standard' image 
formats in order to allow an open approach to information management (e.g. IPI, INTERFILE, DICOM). This is in 
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strong contrast with the long-standing tradition of standardisation in the telecom environment (e.g. CCITT message 
based fax standards). The consequence is that for some time into the future, MIMOSA will have to read, write and 
communicate data in a heterogeneous environment in which some (or most) systems may understand only their own 
and / or a limited number of other data formats. 

In this section, some general considerations about formats will be presented and some typical formats which are used 
to store graphical or pictorial information, both outside and inside the field of medical imaging, described. Two related 
standards, PostScript and HyTime are also reported, briefly, because of their potential importance. 

The value of formats for use in MIMOSA, or by extension in any such system, can be determined by using a set of 
criteria. The first and most important criterion is whether the format covers all aspects of its application domain 
completely, correctly and unambiguously. Implementations are usually minimised in size in order to cover completely 
only those aspects required in a particular scenario. A second criterion is whether a format can logically be related to 
other formats, and therefore be translated. This compatibility criterion has the opposite effect of the previous criterion. 
Indeed, optimal compatibility implies a comprehensive union of all aspects of all application domains. Generic formats 
such as IPI reconcile both criteria as well as the criteria of flexibility and extensibility by embedding the ability to 
adapt to new requirements such as an extension from 2D to 3D. INTERFILE is another example of a flexible and 
extensible data format. With respect to flexibility and extensibility, compatibility with previous versions is a critical 
issue. In an open environment, a format should be able to be ported into different environments. It should be possible 
to integrate the format in the environment such that a wide range of application can use it; an example in graphics 
computing is the TIFF (Tag Image File Format) format. Finally, mechanisms should exist for thorough validation of 
the format. 

In the field of imaging, having a linear list of pixel data only is not sufficient in order to understand and interpret the 
image data. One needs, at least, additional information which specifies the dimensions of the image (e.g. matrix size 
[i]:= ...) and the pixel type (e.g. signed integer), which is the minimal information required to display or process an 
image. 

Depending on the application area and scenario, one may have to add contextual information for two different reasons, 
in order to: 

• add information which is relevant for clinical interpretation, 

• restrict inappropriate operations such as adding images from different patients or different orientations. 

Most medical image formats will provide rules for adding to the image data descriptive attributes concerning the 
patient, the referring clinician, the examination etc. in order to allow their use in particular implicit or explicit 
scenarios. Some formats include those attributes at fixed locations in the image data file. Others use specific labels or 
tags in the same or in a separate 'header' file. Still others allow the attributes to occur somewhere / anywhere in the 
data stream. ANALYZE, being a programme developed mainly for use in a research environment, adds minimal 
information in a separate header file, while INTERFILE adds comprehensive information for its use in clinical nuclear 
medicine, either in a separate header file, or as a header in the image data file. MIMOSA proposes to add information 
required for its use as an image management system to the image data, including: administrative and other 
management data which are not directly relevant for the clinical application, but which are essential with respect to the 
MIMOSA scenarios. One can therefore expect that, today, no existing format will satisfy all MIMOSA requirements, 
but that the mechanisms or the generic character underlying several existing formats may make them good candidates 
to fulfil those requirements eventually. 

While there are many format standards defined or used both outside and inside the area of medical imaging, many of 
which are relevant or potentially important with respect to medical images, the formats indicated here in bold will be 
described in more detail because of their particular characteristics or value. 

Standards with an official status or used world-wide: 

• IPI Image Processing and Interchange, an interchange format and mechanism proposed under the ISO 
organisation and IIF Image Interchange Facility, a substandard to IPI [IPI 1992, Hofmann and Blum 1991] 

• TIFF, developed to facilitate the exchange of raster image data [Aldus 1990], 

• HDF, NCSA generic image format, 

• NetCDF, image format for scientific applications [Rew and Davis 1990], 

• PostScript, a data storage, exchange and programming language mainly used in document output [Adobe 
1985], 

• HyTime, a generic standard for hyperdocuments [Newcomb et al 1991], 

• EDIFACT, a standard for messages and documents widely used (also) in medicine, 

• SQL / RDA, a standard for database query, 

• CMIS / CMIP, a standard for managing objects. 

In medical imaging, the following standards can be cited: 

• ACR-NEMA V2.0, the original US radiological proposal [ACR-NEMA 1988], 
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• DICOM (V3), the updated version of ACR-NEMA [DICOM 1993], 

• MEDICOM, the CEN version of a standard for medical images [MEDICOM 1993], 

• MIPS, the Japanese version of ACR-NEMA, 

• IS&C, Information store and Carry, the Japanese file and medium format for magneto optical disks, 

• SPI, the Siemens and Philips extension of ACR-NEMA - Standard Product Interchange, 

• Papyrus, the extension of ACR-NEMA proposed under the Race project Telemed by the University hospital of 
Geneva, 

• AAPM key value pairs, the file format proposed by the AAPM [Baxter et al. 1982], 

• INTERFILE (V3.3) the nuclear medicine file format based on AAPM [Todd-Pokropek 1992], 

• GIF, a file format proposed in the US for medical data interchange, 

• DIF, an extended TIFF format proposed for use in ultrasound, 

• ANALYZE, a research format developed at Mayo Clinic [Robb 1994]. 

Other standards or proposals which are relevant: 

• HL7 Health Language 7, a terminology for health care terms used in particular in the US, 

• CEN WG 3, a proposal for laboratory messages, 

• CEN-WG 2 MIVOC, a proposal for a vocabulary of terms, 

and in addition the work of some related AIM topic groups (there are many others!), such as: 

• GEHR, general patient record structure, 

• NUCLEUS, the AIM project for clinical act management. 

Note that communication protocols such as Ethernet and FDDI have been excluded in this selection since the standards 
which have been cited are primarily involved at the application layer, e.g. those standards which need to know 
something about the data. 

There are also some standards relevant to medical images, but different in purpose from those previously noted, which 
should be considered, for example: 

• ASN.l Abstract Syntax Notation 1, an ISO defined mechanism for describing data, 

• OOPS, the object programming and design paradigm, 

• EWOS, profiling methodology, 

• ER (entity relationship) diagrams 
and in particular, 

• NIAM, a formalism for defining entities and relationships as used by MIMOSA. 

4.2.3.2. Description of particular formats 
ipi 

Image Processing and Interchange is an interchange format and mechanism proposed under the ISO organisation. IPI 
proposes a single application programmer interface and a single image interchange representation applicable for all 
areas that involve the processing, manipulation and interchange of image data, and hence it is of very generic 
character. Image acquisition, communication and presentation issues are explicitly excluded from the scope of IPI. 
Because of its ISO status, IPI will become effectively mandatory. 

The IPI standard is divided into three parts: 

Part 1: Common Architecture for Imaging (CAI), including overview, architecture, profiles, and conformance. This 
defines a set of data types and a common image representation for use in all other parts of the standard, and also 
defines conformance principles and some implementation rules. 

Part 2: Programmers Imaging Kernel System (PIKS), which is an application programmer's interface. This contains 
the functional specification for operators, tool, utilities, management and control structures, profiles, error 
handling and functional element specification. 

Part3: Image Interchange Facility (IIF), addressing formats and interchange issues. This establishes the definitions and 
coding techniques for the interchange of digital images. By defining a recursive image data structure based on 
specific data types the IIF offers a flexible concept to represent any kind of compound rastered images. The IIF 
syntax is given in ASN.l (Abstract Syntax Notation One, ISO 8824). The data types are basic types like 
INTEGER, BIT- or OCTET STRINGS or combinations of those, like SEQUENCES, SETS or CHOICES of 
basic types. The description in ASN.l does not preclude an encoded representation of data. Encoding is 
performed according to BASIC Encoding Rules for ASN.l (ISO 8825). It results in a machine independent 
description of data types, as well as in an encoding into an unambiguous sequential order for raster images. In 
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IIF, the structural information about the image data is separated from the data itself. 

TIFF 

The Tag Image File Format (Aldus TIFF Developers Toolkit, 1990) was developed to facilitate the interchange of 
raster-image data. The TIFF file structure is based on tags which provide information about the image resolution, 
number of bits per pixel (1 to 8) etc. of the images in an image file. The advantage of using tags is that an application 
can ignore tags if it is not designed to deal with, and new tags can easily be added. This is also true for INTERFILE 
key-value pairs, described later in this text. Each TIFF file has a tag directory that identifies either the tag definition or 
the location of the tags in the file. 

Most formats store image data as a linearised array. In order to allow the manipulation of large images, typical in high- 
resolution raster graphics, the TIFF data are organised in image strips which can be easily individually loaded and kept 
in memory or transferred between applications. The file contains both the tags as the image data. A StripOffsets tag 
contains the offset to the beginning of the bitmap image. 

A TIFF file can contain multiple related images such as a low resolution version of a high resolution image. TIFF and 
HDF have many similarities. 

HDF 

The Hierarchical Data Format is NCSA (National Centre for Supercomputing Applications) extensible format that 
prescribes an annotation mechanism which can describe but is not limited to any kind of image data. Only the lexical 
and syntactic rules are fixed, but no semantics are introduced. NCSA has defined a minimal policy that makes it 
possible to load any type of image with a HDF file. At this level, several 'annotations' have been standardised, being: 
dimension specifications, primitive pixel types, verbatim comments. 

Internally HDF files are implemented with possibly intermixed attribute and data segments. Thus an HDF data stream 
is not necessarily linear, and 'dumb' programmes are generally unable to cope with HDF files. Basically segments 
either contain data elements or symbolic pointers to them. Symbolic pointers are at present implemented as numerical 
tags although this is not a stringent requirement in the HDF standard. Because symbolic pointers can be used to 
implement complicated data structures, such as trees, HDF can also cope with storage requirements of relatively novel 
technologies such as hypertext. Conceptually HDF may be regarded as a file system, with provisions for hierarchy 
management and file typing. The files of the "carrier" file system have a role analogous to physical or logical disk 
blocks in common file systems. The only difference is that HDF focuses entirely on image data management while 
common file systems have provisions for access security checking etc. 

NCSA supplies extensive libraries written both in C and FORTRAN for input-output operations. After a HDF file has 
been opened, the tag directories may be retrieved. A HDF application programme may not be able to interpret all the 
tags. However, a minimal set of tags that describes essential characteristics such as image dimension sizes and pixel 
format has been standardised. Thus in principle any HDF compliant application should be able to load any type of 
multidimensional image data. The tag set itself is extensible and evolves continuously when new tags are added. 
Application programmes that adhere to the HDF standard should remain upwards compatible, regardless of the 
extensions that are contained in data files. Evidently, when an extension is not recognised, it cannot be exploited. A 
programme that is unable to interpret a histogram tag that allows the pixel histogram to be stored alongside a raw 
image will have to recompute the image histogram, rather than reading it form file. 

NetCDF 

The NetCDF format was developed specially to fulfil the needs of the scientific community. The designers wanted to 
have both independence from the logic embodied in certain applications and to be independent of low level machine 
details. To this end they introduce a methodology to describe the syntax of data and a machine independent physical 
storage format. 

For the physical storage format the Sun External Data Representation format (XDR) was chosen. XDR was designed 
by Sun Microsystems to be used as a 'wire' level protocol in heterogeneous Remote Procedure Call (RPC) 
environments. When an RPC is executed, parameters and sometimes results must be transferred between the calling 
and the called procedures. Programming languages such as C describe the primitive data types (integers, floating point 
numbers) usually in terms of the preferred storage entities on the native machine. This means that the binary 
representation of data structures in terms of size, byte order and alignment may be completely different. The XDR 
standard defines a common exchange format, which allows the exchange of binary data between heterogeneous 
architecture. The XDR library procedures translate bidirectionally the data structures. Sun decided to extend this 
approach to stored data, which means that the XDR formatted data can be stored in files. 
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From a conceptual point of view, NetCDF data is described using three abstractions. 'Dimensions' describe systems of 
reference without actually being tied to a physical representation. Internally the Dimension variables furnish 
indirection to the actual physical measurement values. Access to array variables is therefore manipulated in terms of 
natural co-ordinates. 'Variables' contain the raw data. The variables themselves may be of multidimensional nature, 
but again this aspect is manipulated indirectly. Variables may have associated 'attributes'. No interpretation is placed 
on the contents of these attributes. An application can recognise an attribute as such, but it will not always be able to 
interpret its value. A data object can function as an alias for another object. This makes it possible in NetCDF to 
introduce symbolic links to other objects. 

PostScript 

PostScript, developed by Adobe, occupies a unique position as a data storage format because it is at the same time a 
machine independent description of visual two dimensional information (texts, drawings and images) as well as a 
programming language. PostScript can be classified as an external exchange standard. It is generally impossible to 
reverse the PostScript document into a representation that can be manipulated by a text editor. On the other hand the 
programmability offers some unique possibilities. This programmability is effectively used when a PostScript 
document contains its own compression and decompression functions to speed up transmission towards a printer. A 
document might also be defined through procedural descriptions. Candidate images for procedural definition could be 
standardised test patterns, where the procedural aspect results both in a compact description and possibilities for 
parametrisation. PostScript cannot be overlooked because it is the de-facto standard in document output. 

HyTime 

Although not a file format as such, the proposed Hypermedia / Time based Document Structuring Language 
('HyTime', ISO /IEC Draft International Standards 10744) is relevant for this discussion as it is a generic standard 
designed to allow the integration of images, text, sound, movies etc. in a hyperdocument. Its application domain is 
therefore the widest possible. It is built on the Standard Generalised Mark-up Language (SGML ISO / IEC 8879- 
1986). This mark-up language provides information about the structure and the notation(s) of the document in a way 
that is understandable or interpretable by any application that has been provided with an appropriate data importation 
facility. Each tag is represented by a generic identifier. Note that HyTime tags are not formatting codes. The HyTime 
design reflects the view that all multimedia technologies, in the broadest sense, should be able to be competitive. Care 
has been taken to standardise only those aspects of hyperdocument representation that would improve the business 
climate. No provision has been made for standardising user interaction, query language or data notation. 

HyTime is designed to be used modularly. The primary 'Base Module' supports basic utility functions. The 'Location 
Address Module' allows the indication of segments of information, wherever they may reside. The 'Hyperlink 
Module' enables the expression of structural relations and references. The 'Finite Coordinate Space Module' permits 
the specification of spatial and temporal relations. 

The Base Module includes a mechanism that permits the use of xenoforms. A xenoform is a HyTime construct that 
supports the specification of application defined expressions. These might serve in a hyperdocument to access a 
relational database through SQL queries etc. Activity tracking is optionally supported. Currently, only the basic 
mechanism is in place. Any element in an SGML document can have an activity tracking attribute which functions as a 
pointer to an activity tracking policy element. The latter can control creation, modification, linking and accessing and 
deletion of the element under control. 

In the Localisation Module, addressing by Name is the most obvious way to address named entities in a 
hyperdocument. It sets forth the information an application will need to locate the data, to establish a parsing context 
and to retrieve the named entity. Addressing by indicating a position on an axis is provided to indicate portions of 
entities: substrings inside a parent string (string location address), position based on token (word) count, tree location 
addressing (levels in a tree data structure), path location addressing (paths in trees) and Finite Coordinate Space 
addressing (e.g. temporal synchronisation, subpicture in picture...). Addressing by semantic content supports attribute 
location addressing (value of attribute) and notation specific location addressing (xenoforms). 

From the MIMOSA point of view, HyTime is important because it shows how the structure of arbitrary documents can 
be described generically. Because MIMOSA will certainly deal with hyperdocuments, relevant MIMOSA information 
could be structured as hyperdocuments using HyTime. 
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DICOM V3 

Digital Imaging and Communications in Medicine, DICOM version 3, is a major updated version of the former ACR- 
NEMA V2.0 proposal. ACR (the American College of Radiology) and NEMA (the National Electrical Manufacturers 
Association) defined DICOM to allow radiological image transfer. The proposed DICOM standard covers the range of 
ISO layers between application aspects to the physical connector. In its first definition it was restricted to a message 
oriented communication protocol for radiological 2D images, but it now includes provisions for image series and for a 
file format similar to Papyrus. DICOM is not an official standard as neither ACR nor NEMA are standards 
organisations, but it may gain official recognition through MEDICOM. There is a consensus however to accept 
DICOM / MEDICOM as the future standard for radiological image transfer. Hence it is of paramount importance for 
MIMOSA. 

DICOM (as voted on by mid 1994) is composed of 9 inter-related parts: 

Part 1 provides an overview of the standard. This details the design principles, defines the terms used, and gives a brief 
description of each part. 

Part 2 defines conformance to DICOM and what conformance means. This explains how manufacturers claiming 
conformance to DICOM should write conformance statements. These documents describe in an unambiguous 
way how their products conform to DICOM, and will guide users in selecting products that should work together 
and may also help them to define a conformance requirement, as a part of a purchasing agreement. 

Part 3 describes Information Objects (Information Object Definitions or IODs). Explicit Entity-Relationship diagrams 
are given. A difference is made between Normalised objects (such as Patient, Visit, Study, Study Component, 
Results, Interpretation, and Print related objects) and Composite objects (such as CAT Image, MR image, 
Overlays, Lust and Curves). Objects are characterised by attributes, for example 'Study' with attributes 'Study 
Date' and 'Study Time'. 

Part 4 contains the Service Class specifications. The services are considered as operations performed on the 
information objects (Service Object Pair Classes or SOP Classes). The role of the User (Service Class User) and 
the Provider (Service Class Provider) are defined as well as the expected behaviour for each role in each service 
class. Examples of Service Class are Storage Service Class, Patient Management Service Class, Query / Retrieve 
Service Class. 

Part 5 details how data should be encoded. 

Part 6 is a dictionary of all data elements used, with their representation (e.g. text, integer), multiplicity value, allowed 
values (for those that can take only certain values). 

Part 7 describes the message exchanges necessary for requiring or providing a DICOM Service (DICOM Message 
Service Element or DIMSE). The standard makes a distinction between normalised and composite services 
(DIMSE). For example the Storage Service Class is composite, which involves the use of the C-STORE Service 
(C-STORE-Request and C-STORE-Response). N-CREATE is normalised. Normalised DIMSEs are based on the 
CMIS / CMIP services and protocols whereas Composite DIMSEs are based on message exchanges defined in 
ACR-NEMA V2.0. 

Part 8 defines the network support for exchanging the DICOM messages. Both TCP / IP and OSI stacks of protocols 
are used. 

Finally, Part 9 specifies the ACR-NEMA V2.0 50-pin interface, for compatibility with previous versions. 

The latest additions to DICOM (parts 10, 11, 12) is the file format proposal and media storage definition, currently 
being defined. New Information Objects are also in the process of being defined. 

As stated before, DICOM has strongly linked with the forthcoming European MEDICOM standard proposal. DICOM 
has the backing of the radiological industry and community. It is therefore essential that the correspondence between 
the functionality of DICOM and the requirements of MIMOSA be studied. 

MEDICOM 

MEDICOM represents the European standard proposal in the field of medical imaging. This initiative was launched in 
1991 by CEN, the European official body for standardisation. A technical committee and seven working groups were 
set up (TC 251) to prepare standards in the area of Medical Informatics. Among these groups, one deals with "Medical 
imaging and multimedia". The working plan addresses a number of key aspects for which standardisation is required: 



Code 


Acronym 


Title 


4.1 


FPMI 


Functional profiles for medical image interchange 


4.2 


IMS 


Medical image management standard 


4.3 


MIF 


Medical image and related data interchange format standards 
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4.4 


CCMIP 


Standard classification and codes for medical image processing 


4.5 


CALIMACS 


Patterns for calibration of IMAC components 


4.6 


CARIMACS 


Characteristics and specification standards for IMACS components 
and systems 


4.7 


CTSI 


Medical image interchange: Conformance testing of standards 
implementation 


4.8 


COMPR 


Medical image interchange: compression schemes in Telemedicine 


4.9 


HIS RIS PACS 


Medical Data Interchange: HIS/RIS-PACS and HIS/RIS- 
Modality Interface 


4.10 


MMRIDF 


Medical Multimedia and related interoperability data format 


4.11 


EPAS 


Evaluation of physiological analysis systems 



These topics (as of 1994) are addressed either by WG 4, or by EWOS, the European standardisation body specialised 
in Open Systems Interconnection (namely items 4.1 and 4.7). 

The major result obtained has been the production of a document which is currently undergoing the so-called "Red 
cover procedure", a formal TC251 procedure to gather the approval from the member countries. This document 
proposes effectively to adopt DICOM as a European standard for medical image interchange (4.3). More precisely, 
MEDICOM suggests the adoption of the following parts of the DICOM standard: 

Part 2 - Conformance 

Part 3 - Information Object Definitions 

Part 4 - Service Class Specifications 

Part 5 - Data structure and Encoding 

Part 6 - Data Dictionary 

Part 7 - Message Exchange 

Part 8 - Network Communication Support for Message Exchange 
Part 10 - Media Storage and File Format {potentially } 

Part 1 of DICOM has been replaced by the MEDICOM document, and Part 9 is not supported because it was only 
included in DICOM for historical reasons (50-pin interface). 

The MEDICOM document proposes a roadmap for further development of the standard, in particular to integrate 
concepts and standards from the IPI-IIF standard (ISO 12087-3). 

• After a first step of adopting DICOM, parts of the standard will evolve as a result of a joint activity of WG 4 and 
ACR-NEMA (extension of existing information objects, creation of new information objects, new service classes, 
etc. 

• A second step is intended to include profiles allowing import / export of image pixel and pixel attributes defined 
by IPI-IIF, in order to permit the exchange of image pixel data to and from image processing kernels compliant 
with the IPI-IIF standard. 

• A third step consists of integrating native IPI-IIF images within DICOM / MEDICOM objects, which would both 
facilitate the exchange of IPI based image processing kernels and medical imaging equipment, and broaden the 
current DICOM / MEDICOM image representation model. This third step will actually take place only if image 
processing based on the IPI-IIF standard becomes widespread. 

• Further long-term steps consider the full integration of image objects in a multi-media format. 

INTERFILE 

INTERFILE has been defined under the framework of the European COST-B2 project (EC / DGXII) which is 
concerned with the development of appropriate mechanisms for quality assurance of nuclear medicine software. To 
this end the project is developing a number of software phantoms based upon both real patient data and mathematical 
phantoms in order to test the validity of various application programmes used on a variety of different nuclear 
medicine computers. The key feature of INTERFILE is to use an ASCII file or 'header' in which 'key-value pairs' are 
used to describe the various attributes of the image data file, the 'key' being the name of some attribute having a 
specified 'value'. An example is "number of bytes per pixel:= 2". 

It must be stressed that INTERFILE is conceived as a file format specification, primarily a data dictionary, and not as 
a complete mechanism for transferring nuclear medicine files from place to place. In this respect it is different from the 
previous ACR-NEMA standard which was mainly a communication protocol. Thus it is expected that INTERFILE can 
be used to translate files from a variety of different manufacturers, while the files themselves are transferred between 
systems using whatever means are appropriate, for example: floppy disks, RS232 lines, modems, Ethernet etc. 
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INTERFILE is not in competition with ACR-NEMA or DICOM / MEDICOM since work has also been undertaken so 
as to translate ACR-NEMA data (a snapshot of an ACR-NEMA message) into INTERFILE and vice versa. Ongoing 
work is also being undertaken to harmonise the DICOM / MEDICOM and INTERFILE data dictionaries. 

While INTERFILE is not specific to nuclear medicine data files (it can and has been used for other types of data such 
as CT, MRI etc.), the keys endorsed today by COST-B2 are specific to and intended to be used for nuclear medicine 
image data files. While other proposals have been made for handling images, that is, to ensure that the display of such 
data can be reproduced on other equipment, using formats such as TIFF (including the definition of colour scales etc.) 
this is not the concern of INTERFILE. INTERFILE is designed such that the image and associated data can be 
transferred and understood on different machines, so that, for example, the data acquired as a gated study on one 
machine can be processed on another. It should be noted that INTERFILE has also been endorsed by the Society of 
Nuclear Medicine, but that its use in radiological image transfer is likely to be of minor importance. INTERFILE will 
therefore be studied in relation to the MIMOSA requirements, but in much less detail than DICOM / MEDICOM. 

ANALYZE 

ANALYZE is an image processing application programme developed at the Mayo Biotechnology Computer Resource, 
Mayo Clinic, Rochester MN, and running on different workstation platforms. The application domain of ANALYZE is 
typically a clinical research imaging environment. It allows multidimensional manipulation of images originating from 
different modalities. 

An ANALYZE image data base consists of an image data file (xyz.img) and a separate binary header file (xyz.hdr). 
The header file contains 3 sub-structures, being: Header_key, Image_dimension and Data_history. The Header_key 
mainly specifies the byte size of the header file. The Image_dimension specifies the number of dimensions in the data 
base (e.g. 4: t,z,y,x) and the number of pixels, slices or time points for each dimension. It also specifies the data type 
(1 to 64 bits per voxel), the correspondence between voxel dimensions and measurements in mm. or ms. The 
Data_history is an optional sub-structure in which attributes such as orientation can be indicated. 

The ANALYZE format has been optimised for use in an environment where a minimal knowledge about descriptive 
attributes is required. 

4.3. Choice of an architecture for the 
MIMOSA system 

4.3. 1. Proposed Architecture: a general presentation 

The MIMOSA functional and dynamic models identify a number of internal MIMOSA functions, which are detailed in 
the models, and also refer to external functions (e.g. Access Rights control, or Act Management) that are not detailed 
in the models. However, this distinction does not impose any constraint regarding the actual implementation of the 
information system. Many implementation architecture can be envisaged: for instance, it may be relevant to consider 
that a function such as the Acquisition Preparation function should be implemented in the same sub-system as a RIS 
Act Management System. 

The following sections detail and justify one particular choice for a MIMOSA-compliant Architecture. 

This architecture results from the analysis conducted during the specification of a MIMOSA Prototype at the Rennes 
University Hospital (figure 4.3.1-1). This is only one example of various possible architecture. Moreover, it should be 
clearly stated that it does not take in account all possible features of MIMOSA, but only those which were relevant for 
this particular implementation. 

The resulting system can be divided in three interacting parts: 

• The MIMOSA Engine: this centralised sub-system provides the external entities with a number of image 
management services, such as: 

- act preparation (acquisition, processing, reporting), 

- data consultation, 

- acts related worklists management, 

- entering of new images, 
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- entering of multimedia reports; 

• The Data Availability and Storage Management sub-systems: these centralised sub-systems provide the 
MIMOSA Engine with internal services, consisting in managing the distribution of image copies over the different 
MIMOSA directories; 

• A set of MIMOSA Directory Managers (MDM): this distributed set of storage sub-systems implements the 
services related to the management of image data and storage areas (copy / move service, export service, delete 
service, inquire service). 

4.3.2. Proposed Architecture: additional details 

4.3.2.1. The MIMOSA engine 

The associated services are provided by a set of centralised managers: 
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• The Operation preparation managers 

- Acquisition Preparation Manager 

• Acquisition Schedule Receiver. This waits and receives Acquisition Requests sent by the HIS / DIS Act 
Management System; 

• Exam Data Requester. This allows the MIMOSA engine to get the detailed characteristics of the patient 
and examination related to a particular Acquisition Step, if needed; 

• Acquisition Step Scheduler. This allows an external application (acquisition) to receive or update the 
acquisition worklist, upon or without request of the external entity; 

• Acquisition Step Data Provider. This provides an external application (acquisition) with the detailed 
characteristics of an acquisition step, upon request of the external entity; 

- Reporting Preparation Manager 

• Reporting Schedule Receiver. This waits and receives the Reporting Requests sent by the HIS / DIS Act 
Management System; 

• Examination Data Requester. This allows the MIMOSA engine to get the detailed characteristics of the 
patient and examination related to a particular Reporting Step, if needed; 

• Examination Status Provider. This allows an external application (reporting) to be informed of events 
related to the examinations to be reported, such as "Acquisition Step Completed"; 

• Reporting Step Scheduler. This allows an external application (reporting) to receive or update the 
reporting worklist, upon or without request of the external entity; 

• Reporting Step Data Provider. This provides an external application (reporting) with the detailed 
characteristics of a reporting step, upon request of the external entity. 

Remark: 

A similar organisation can be designed for the management of Processing steps. 

• The New data managers 

- New Image Manager 

• Image Import manager. This waits and receives the Import requests sent by an external application 
(acquisition) and generates the import request towards the DAM. When an import has been completed, it 
reports to the requesting application about the completion of image imports; 

• Acquisition status provider. This waits and receives the indication that the Acquisition Step is complete; 
which means that, normally, all images related to this Acquisition Step have been imported; 

• Study status provider. When all images related to a completed Acquisition Step have been imported, the 
Study status provider informs the HIS / DIS Act Management System that the Acquisition Step is complete; 

- New Report Manager 

• New report service provider. This waits and receives the new reports sent by an external application 
(reporting); 

• Interpretation status provider. This waits and receives the indication that the Reporting Step is complete. 
This means that, normally, all images related to this Acquisition Step have been imported; 

• Study status provider. When the report related to a completed Reporting Step has been entered, the Study 
status provider informs the HIS / DIS Act Management System that the Reporting Step is complete; 

Remark: 

A similar organisation can be designed for the management of Processed Images. 

• The Data Consultation Manager: 

- Query Service Providers 

• Patient related query service provider. This offers services to: 

. select patients according to user-defined selection criteria, 
. retrieve the detailed characteristics of a particular patient; 

• Clinical Request related query service provider. This offers services to: 

. select Clinical Requests according to user-defined selection criteria, 
. retrieve the detailed characteristics of a particular Clinical Request; 

• Examination related query service provider.This offers services to: 

. select Examinations according to user-defined selection criteria, 
. retrieve the detailed characteristics of a particular Examination; 
. list the Image Objects belonging to an Examination 
. list the Examination Steps belonging to an Examination 
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. get the Report of an Examination 

- Image Export Manager 

• Examination Export service provider. This lists the Image Objects belonging to an Examination and 
generates export requests towards the DAM to export the images to the selected consultation platform; 

• Image Object Export service provider. This generates export requests towards the DAM to export the 
images to the selected consultation platform; 

4.3.2.2. The Data Availability Manager (DAM) & Storage Access Server 

This sub-system has three components: 

• The DAM Request Manager: 

- Import Request Handler. 

This receives the Imports Requests and processes them. In particular, it applies Configuration Rules and uses 
Configuration Information to determine the most appropriate MIMOSA directory and Import Service Type and 
generate the Import Command towards the MIMOSA Directory Access Server. 

- Export Request Handler. 

This receives the Exports Requests and processes them. In particular, it applies Configuration Rules and uses 
Configuration Information to determine whether the actual export should be delayed or not (to cope with the 
expected data & time of the export), choose the most appropriate source copy and Import Service Type, and 
generate the Export Command towards the MIMOSA Directory Access Server. 

- Availability Request Handler: 

• New AR Handler. This receives the New Availability Requests and processes them. In particular, it applies 
Configuration Rules and uses Configuration Information to determine whether existing copies can fulfil 
them. If this is not the case, it may generate the Move or Duplicate Commands directed to the MIMOSA 
Directory Access Server. 

• Expired AR Handler. This scans the Expired Availability Requests and processes them. In particular, it 
applies Configuration Rules and uses Configuration Information to determine whether copies can be 
deleted. If this is the case, it generates Delete Commands directed to the MIMOSA Directory Access 
Server. If, on the other hand, this is not the case, it checks whether existing copies related to the Expired 
Availability Request should be moved to more appropriate MIMOSA directories; and, if this is the case, it 
generates Move or Duplicate Commands directed to the MIMOSA Directory Access Server. 

• The MDM Access Server 

DAM Command handler. Its role is to synchronise the access to the distributed MIMOSA Directories, and 
external applications (for image objects import). Several commands sent by the DAM may involve the same 
resources and must therefore be executed sequentially. It also performs flow control, in order to limit the number 
of concurrent transactions. It forwards to the distributed MIMOSA Directory Managers (MDM) and external 
applications commands to move or delete Image Objects, or to get information about the storage resources 
available, as requested by the DAM. It receives the confirmation about the commands completion from the 
distributed MDM and external applications; if time-outs expire, events are generated directed to the DAM 
Request Manager. 

- Administration Request manager. This receives and processes requests sent by the administration application, 
which may request information about the DAM commands being processed (import command, export command, 
move command, duplicate command, delete command, inquire command) or cancel pending commands. 

• The MDM Client Access Layer 

This MDM Client Access Layer is an interface layer which allows the Data Availability Manager to communicate with 
the MDM Access Server. The MDM Client Access Layer can also be used by the Administration application, 
providing it with the ability to directly interact with the MDM Access Server (figure 4.3.2.-1). 

4.3.2.3. The MIMOSA Directory Manager (MDM) 

The MIMOSA Directory Managers are distributed entities responsible for the management of the MIMOSA 
Directories. By distributed, it is implied that an MDM may be implemented on different hardware platforms (e.g. a 
central server or workstations). MDMs execute the commands decided on by the DAM and received through the 
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MDM Access Server. MDMs are composed of two parts: 

• MDM Service Provider. This receives the commands sent by the MDM Access Server or other MDMs or 
External Application Entities, and forwards them to the MIMOSA MDM Application Entity, so that they can 
actually be executed. In turn, the MDM Application Entity calls the MDM Service provider to request the 
execution of a command by other MDMs or External Application Entities. The services provided are: import, 
move, duplicate, export, delete, provide information, store, and delete. 

• MDM Application Entity. This processes the service call, upon request from the associated MDM service 
provider. The execution of a command (for example, a move command) may necessitate MIMOSA services to be 
requested from another MDM or External Application. For example, the execution of a move command may 
necessitate that the application entity becomes a user of a store service provided by another MDM or External 
Application. Thus, an Application Entity may be either user or provider of a MDM Service. MDM Application 
Entities handle the specifics of each MIMOSA Directory in terms of retrieving the access path to the image data, 
reading or deleting them, or providing the requested information (e.g. available space). 
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figure 4.3.2-1: Data Availability Manager (DAM) and MIMOSA Directory Manager (MDM) sub-systems 
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4.3.3. Rationale of the architecture 

A number of factors which may influence the choice of an architecture have been briefly presented in the introductory 
section (see § 4.1). The choice of architecture is discussed in the light of those factors in the following section. 

4.3.3. 1. Different kinds of data managed 

The entities of the MIMOSA data model can be classified in five categories, with little overlap between them: 

- Examination Context entities (such as Patient, Clinical Request, examination, Examination Step) describing the 
general context of production and utilisation of medical images; 

- Image Object descriptions (such as Image Object element, Image Object Version, Image Object Variable, Image 
Object Component, Image Object Version, Image Object Representation, Image Object Copy, etc.) describe the 
internal characteristics of Image Objects; 

- Image Data entities, describe the actual content of image copies; 

- Configuration entities (such as MIMOSA directory, platform, Transport between Directories and Platforms, 
Transport from Directory to Directory, Configuration rule, etc.) describe the actual PACS configuration; 

- Image management entities (such as Import Request, Export Request, Availability Request, Import Command, 
Export Command, Availability Command, Delete Command, etc.) are used for management. 

Table 4.3.3-1 shows some characteristics of the MIMOSA entities: 
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Table 4.3.3-1: Characteristics of the MIMOSA data model entities. (*: low - **: medium - ***: high ). 



It appears from table 4.3.3-1 that the different categories of entities show very different characteristics in terms of data 
volume, number of entities and complexity of relationships. Consequently it may be appropriate to implement them 
within separate sub-systems. However a such choice must also take into account how the entities are implicated in the 
various different functions (see the next section). 

In particular images raise special problems due to the very high and variable volumes of data involved (ranging from a 
few Kilobytes or Megabytes for Nuclear Medicine image series, to hundred of Megabytes in cardiac angiography, for 
instance). This concern forced a comparison to be made of several possible strategies regarding the management of 
image data. Initial attempts, in terms of the choice of architecture, indicate considering a single module responsible for 
receiving, buffering and converting the new images sent by external applications. It turned out that a more appropriate 
strategy would be to make a clear distinction between the sub-systems actually manipulating image data (MIMOSA 
Directory Managers), and others which only manage image related data or image copy locations. This latter solution 
was finally agreed upon since it is compatible with the constraints arising from the special nature of images. 

4.3.3.2. Sharing of the data 

Table 4.3.3-2 shows the implication of each category of entities in the three major sub-systems: 

It appears that the information involved in worklist management, data consultation, entering of new images or new 
reports (or addenda) strongly overlap. Consequently, it seemed reasonable to associate all these functions in the same 
sub-system (MIMOSA engine). In addition, it appears in table 4.3.3-1 that the information used by the MIMOSA 
engine is primarily the examination context information, which confirms that such a decomposition is judicious. 

The information used by the DAM is rather different: only configuration information, configuration rules and copies 
are really necessary, as well as the requests (Data Availability Requests, Export Requests, Import Requests) and the 
related commands (Move Commands, Delete Commands, Import Commands, Export Commands and Inquire 
Commands). 

MIMOSA Directory Managers only manipulate image data, responding to commands generated by the Data 
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Table 4.3.3-2: Implication of the MIMOSA data model entities in the 3 major sub-systems 
(0: no implication, *: small implication, **: medium implication, ***: strong implication) 



4.3.3.3. Performance issues 

As previously mentioned, general information about patients, examinations, reports, etc. must be rapidly available for 
the completion of many functions such as preparation of an act, management of worklists or management of new 
images. Consequently, it was found to be preferable to keep a copy of this information within the MIMOSA system, 
rather than requesting this information from the RIS / DIS Act Manager each time it is needed. 

As previously stressed, the nature of images (for example the volume of the data) creates particular constraints, as a 
result of which a concern about performance arises. This concern was another factor in favour of an architecture taking 
into account the specific nature of images. For instance it was decided to implement the import of images in MIMOSA 
in three steps, rather than one as initially proposed: i) the external application first declares the image object to be 
imported, then ii) the system determines the appropriate MIMOSA directory into which the image should be imported 
(taking into account configuration rules, as well as the storage space available in the candidate MIMOSA directories), 
and finally iii) the system activates the actual transfer of image data. This strategy permits avoiding the initial transfer 
of data into an import buffer, which is inefficient. Moreover, explicit negotiation of the necessary storage place avoids 
useless data transfer, and contributes to increased implementation efficiency. 

This concern also led to refining and extending the role of the MDM Access Server. Indeed, the Data Availability 
Manager does not take into account the detailed ordering and synchronisation of the commands sent to the MIMOSA 
Directory Managers. It is essential that a MDM is not overloaded by several simultaneous image transfers. One of the 
tasks to be fulfilled by the MDM Access Server is to queue the commands to be forwarded to the concerned MDM, 
and eventually reject requests in case of overload of a part of the system (rather than risking a complete deadlock). In 
addition, it is very important to detect very rapidly the eventual failure of a data transfer, in order to abort it, and free 
the resources for other pending transactions. 

4.3.3.4. Existence of standards 

This factor was certainly the most important. Two different aspects had to be addressed: 

- the problem of image representation and formats, and 

- the communication between the MIMOSA Server and the External Applications. 

• Regarding the first aspect, it appeared from the analysis of existing standards that it would be too constraining to 
adopt a single image representation format. Indeed many formats such as TIFF, Postscript or DICOM Part 10 could be 
used, with advantages and drawbacks related to each. In the long term, it is expected that DICOM Part 10 will emerge 
as the most important storage format, but this is not yet sure. Consequently, it was decided that several representation 
formats could be used, in other words, that the application entities associated to the MIMOSA Directory Managers are 
free to use the image format they feel to be the more appropriate. In particular, these applications may store the data of 
an image object (called an image series in the DICOM terminology) in one or several files. In terms of architecture this 
means that the modules delivering the MIMOSA services (in a general and homogeneous way) have to be 
distinguished from those manipulating the data in a site or medium specific way, and a clear interface has to be defined 
between them. In a similar way, it was decided that the notion of access path to an Image Object had to be discarded, 
since it is necessarily dependent on implementation (for example using simple UNIX files as opposed to an object 
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oriented database). These issues had repercussions with respect to the MIMOSA model itself. Indeed, the primary 
option consisted of adopting a common representation of images throughout the MIMOSA system. Therefore, 
conversion between external representation formats and the reference format was considered as one of the tasks to be 
performed by the MIMOSA New Image Management function. 

• In terms of information exchange between the external applications and the modules offering MIMOSA services, the 
utilisation of standard communication protocols is absolutely essential, in order to permit multi-vendor systems to be 
implemented. With respect to this issue, the publication of the DICOM standard in 1993 and 1994 was a major event 
in the area of PACS, and it is not certain that DICOM / MEDICOM will have a major impact with respect to 
interfacing medical imaging equipment in the future. However, the philosophy and methodology of the MIMOSA 
topic limits the consideration of existing standards to "the choice of an implementation architecture and 
communication protocols able to implement the MIMOSA model derived from the analysis of the users requirements". 

In practice, taking into account the existence of DICOM / MEDICOM consisted of raising the following questions: 

a) Is the DICOM / MEDICOM information model consistent with the MIMOSA data model ? 

This first question is partially addressed in Appendix 9. Comparison between the MIMOSA and DICOM data models 
(Examination Context). The term DICOM is used to indicate the DICOM / MEDICOM standard. This appendix 
provides a general mapping of MIMOSA concepts onto DICOM information objects, and discusses in detail the 
differences between them. 

It appears clearly from this study: 

1) that a rough correspondence can be established between: 

the MIMOSA Patient entity and the DICOM Patient Information Object 

the MIMOSA Patient Location entity and the DICOM Visit Information Object 

- the MIMOSA Examination entity and the DICOM Study Information Object 

- the MIMOSA Examination Step entity and the DICOM Study Component Information Object 
the MIMOSA Image Object entity and the DICOM Series Information Object 

- the MIMOSA Report entity and the DICOM Interpretation Information Object 

- the MIMOSA Addendum entity and the DICOM Interpretation Information Object 

This match is sufficiently close to allow the major aspects of the interworking between the HIS / DIS Act Management 
System, the MIMOSA system and the acquisition, processing or reporting applications to be implemented. 

2) However, it appears that the MIMOSA model also contains a number of concepts which cannot be properly 
conveyed using the DICOM standard. These include: 

- the MIMOSA Clinical Request entity, which details in a more explicit way the motivations of a set of logically 
related examinations; 

- the MIMOSA View on Patient Record entity, which allows the selection of examinations by means of criteria 
related to clinical criteria (such as pathology), in a both powerful and simple way; 

- the MIMOSA Examination Step entity (which may be specialised in Acquisition Step, Processing Step and 
Reporting Step) allows the detailed representation of the resources scheduled or actually used during an 
Examination Step. 

- the MIMOSA Opinion Request and Opinion entities, which allows texts (or voice) to be associated with images 
in an explicit way. 

With respect to these limitations, the general attitude of MIMOSA has been to highlight in detail the current 
limitations of DICOM / MEDICOM and submitting modification proposals to the standardisation bodies, namely CEN 
(through TC251 /WG4 "Medical Imaging and Multimedia") and the ACR-NEMA committee, when appropriate. 
The feedback from the MIMOSA work to the standardisation process was a constant concern within the WP 4 
Workpackage. 

b) Is it possible to implement the functional interactions of a MIMOSA compliant system by using 
DICOM I MEDICOM communication services classes ? 

The following section (§ 4.3.4.) gives some indications concerning this question, related to the MIMOSA functional 
model, and in particular to the implementation of MIMOSA external flows. 

4.3.4. Proposed architecture and the DICOM 
/ MEDICOM standard: a functional point of view 

Considering the functional requirements of a MIMOSA4oased Image Management System, two major factors are very 
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important in guiding the choice of a particular architecture: 

• MIMOSA Model Compliance. The chosen architecture must support the implementation of MIMOSA Functional 
and Dynamic Models, whose design was primarily focused on medical users requirements rather than on 
implementation constraints; 

• System Openness. This architecture must be implementable in various environments, and in particular the 
resulting system must be able to operate in a highly heterogeneous environment; and must permit the integration 
of various multivendor imaging equipment. 

This section covers more specifically issues of system openness, and is consequently more focused on the external 
interfaces of the system with its environment (in particular the HIS / DIS Act Manager, Images Sources and Images 
Users). 

Very early on in the analysis of standards, DICOM 3.0 was selected as being the central standard to be considered. It 
was obvious that DICOM was becoming the most complete and world-wide accepted standard in the particular domain 
it covers. The pragmatic and evolutive approach retained by ACR-NEMA for the definition of this standard make it 
possible to base a long term strategy on the use of it. 

DICOM / MEDICOM (i.e. DICOM for short), like the MIMOSA topic itself, does not cover all requirements resulting 
from the implementation of an actual and operational Image Management System, for example: security, system 
monitoring, PACS overall management, etc. But, for all aspects covered, such as, Images Data Exchange, 
Patient / Study Consultation, Radiological Acts Scheduling - a requirement was adopted that all messages exchanged 
by a MIMOSA Image Management System with its environment would have to be DICOM-compatible. 

It appeared that the MIMOSA functional approach was very consistent with DICOM communication Services Classes. 
We did not encounter any major difficulty in designing an architecture both compliant with the DICOM and MIMOSA 
Models. 

Table 4.3.4-1 summarises the mapping between MIMOSA external functional flows and DICOM services as resulting 
from the analysis. It shows how DICOM Services Classes may be used in the MIMOSA architecture. 

Some more details concerning this functional mapping are given in Appendix 10. 
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figure 4.3.4-1 External Functional Flows & DICOM Standard 
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This chapter concerns the two MIMOSA prototypes that are being implemented at the Rennes University Hospital and 
at the Hospital of Luxembourg. The aim is to give the technical and clinical motivations for both prototypes, to 
indicate the limits of these implementations, to describe the technical approach and resulting architecture, and to 
present first conclusions resulting from the implementation process. 

5.1. Motivation for the MIMOSA 
demonstrators 

In order to validate and demonstrate the pertinence of the MIMOSA modelling approach, concrete experiences are of 
primary interest. Three levels of experimentation can be identified, depending on the goals pursued: 

1) Software simulation is very convenient for identifying key concepts and control the overall coherence of the 
model(s). 

2) Prototyping (design and implementation) is very valuable for identifying architecture issues and for 
verifying that key concepts are implementable. 

3) Demonstration in a clinical context is absolutely necessary to measure the added value of the model to 
clinical routines. 

In 1993, clinical cases presented in appendix 8 was part of the simulation phase. 

In 1994, MIMOSA experimental is centred about prototyping. This work was focused on two major aspects of the 
MIMOSA functional model: 

• The Advice Request Process, to permit co-located or remote clinicians to exchange opinions on pre-selected 
exams. 

• The Data Availability Management, a key concept in order to guarantee users timely access to the examination 
related data (images and reports). 

The demonstration in a clinical context, which is out of the scope of the MIMOSA topic, is scheduled at Rennes to 
take place in 1995. 

The two prototypes developed during 1994 are: 

A PACS prototype implementing MIMOSA Data Availability mechanisms and Examination Context concepts is under 
evaluation at the Rennes University Hospital. After a first phase of experimental work and ad hoc improvements of 
this preliminary prototype, the next objective, during 1995, is to transform it into a MIMOSA clinical demonstrator 
that will be used by Health Care Professionals in clinical routine conditions. By continuing the evaluation beyond the 
scope of the EuriPACS project itself, it is intended to illustrate how valuable the MIMOSA approach is to achieve an 
integrated solution in real clinical environment. This second phase MIMOSA demonstrator will be the opportunity for 
Rennes clinical site to extend its current SIRENE II PACS by the integration of archiving and data distribution 
capabilities. 

Concurrently, a tele radiology-focused prototype has been developed in co-operation with EuriPACS / IMPHONE 
topic. It includes the MIMOSA Advice Request mechanisms along with more specific IMPHONE teleradiology 
mechanisms. An evaluation of this prototype is underway between LUXEMBOURG and Pisa using an Internet Link. 



5.2. MIMOSA Implementation at Rennes 

The paragraph 5.2.1 presents the main objectives of the two Rennes demonstrators. In paragraph 5.2.2. the 
methodology is described following from the choice of the scenario to be implemented when developing the prototype. 
In paragraph 5.2.3. the chosen scenario is described, including the specific users requirements and the constraints 
associated to the site environment. After defining in paragraph 5.2.4. the prototype's key characteristics, in terms of 
features, data and architecture, the design process is described in paragraph 5.2.5. 
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5.2.1. Objectives 

The Rennes prototype has two major objectives: 

1) Assessment of the ability of MIMOSA model to cope with a specific interpretation scenario, in order to obtain 
a partial proof of its genericity. This scenario has been chosen as being one of the most commonly encountered at 
the University Hospital of Rennes. 

2) Evaluation of feasibility and identification of major issues regarding the implementation of those parts of 
MIMOSA model that are involved in the selected scenario. 

The initial prototype is intended to collect preliminary users opinions concerning the MIMOSA approach, especially 
to propose amendments and refinements in the analysis and in user interfaces. A more complete demonstrator will then 
be integrated in SIRENE II PACS during the year 1995 and used in clinical routine conditions. The Rennes 
demonstrator will extend the set of clinical users, which had been deliberately restricted during the prototype phase, in 
order to obtain more complete information concerning the added value of MIMOSA. It will also be possible to get a 
realistic measure of performance enhancement resulting from the implementation of MIMOSA concepts such as Data 
Availability Management. 

5.2.2. Methodology 

5.2.2.1. Basic inputs 

The first step was to define, in co-operation with the future users, the clinical scenario to be covered by the prototype. 
This clinical scenario was then translated into a data flow diagram with a detailed chronology of the associated events. 
In this first approach, the overall system was modelled from a user view point, independently of MIMOSA model. 

The second step was to identify the MIMOSA functions involved in the scenario and the MIMOSA data concepts to 
be manipulated. 

A third step was the refinement of users' requirements by confronting the 'translation' of the scenario by MIMOSA 
with the users' viewpoint. 

5.2.2.2. Site environment and constraints 

From the MIMOSA viewpoint, it was extremely important to distinguish clearly the portable, site-independent 
developments from the site-specific extensions. Two major functional layers were identified: 

• The MIMOSA core function layer, which was required to be implemented as a site-independent MIMOSA 
kernel. 

• The adaptation layer that copes with the specific features of the existing components of the SIRENE II PACS. 
This intermediate layer is the interface required for complete interoperability with MIMOSA core functions. 

The communication between the MIMOSA kernel and components of the adaptation layer was based on existing or de 
facto standards in order comply with the MIMOSA Open System philosophy. 

The figure 2.2-1 depicts the general architecture of the MIMOSA Demonstrator being implemented at Rennes. 

5.2.2.3. Planning 

After assessing the resources available with respect to the ambitious objectives being pursued, it was decided to 
implement the MIMOSA demonstrator in two steps: 

• A preliminary prototype was developed, centred on architecture issues and implementability of key concepts. 
This first prototype was not intended to be used in clinical routine, even though integrated in the existing PACS. 

• A complete MIMOSA demonstrator was planned to be developed from the prototype and evaluated in clinical 
routine usage, primarily in 1995. 

5.2.2.4. Overall system analysis and design process 

A classical function-driven methodology was applied in order to define and design the overall system. The major steps 
were: 

• system functional specification (primary, administrative and monitoring functions), 
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logical architecture design, 

organisational specifications, 

dynamic analysis and implementation design. 
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External world 




I 

figure 2.2-1 : MIMOSA Demonstrator General Architecture 
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The overall analysis and design process covered both the preliminary prototype and the future demonstrator. 

5.2.2.5. Implementation philosophy 

The MIMOSA Rennes prototype has been developed thanks to the co-operation between General Electric Medical 
Systems (GEMS) and the Nantes-Rennes-Villejuif association, both members of the EuriPACS consortium. CERIUM, 
located at the Rennes University Hospital as a sub-contractor of NRV, was responsible for site specific developments. 
GEMS was more specifically responsible for the development of a site independent MIMOSA kernel. 

After a global specification of the overall system as part of the SIRENE II PACS, a step by step development plan was 
scheduled. Four axes for development were identified, each corresponding to a specific point of view: 

• the function axis : which MIMOSA functions and concepts are implemented? 

• the interoperability axis : how open is the system (standard interfaces, ...)? 

• the management axis : how manageable and secured is the system? 

• the clinical axis : what are the limits for clinical usage? 

Each implementation (first prototype, future demonstrator and clinical system) can be characterised by a specific place 
on each of these axes. First prototype mainly concerns the functionality axis and the interoperability axis. The next 
demonstrator focuses on the management axis and investigates the clinical axis. Such a development model allows the 
implementation to be focused on well identified goals, without mixing problems of different nature. 

5.2.2.6. Technical assessment 

The 1994 prototype was mainly focused on functional aspects, in order to assess the ability of MIMOSA model to 
cope with the selected scenario. The major goal was to verify that the corresponding concepts and derived system 
requirements were implementable, and (furthermore) that it was possible to add MIMOSA-based features to an 
existing operational clinical PACS. 

5.2.2.7. Experimental work 

The 1995 demonstrator will be focused on interoperability and system management aspects, in order to prepare for its 
integration in the clinical environment. The routine usage of the demonstrator will then allow the assessment of the 
clinical added values of MIMOSA. 

5.2.3. Scenario, requirements and constraints 

5.2.3.1. Scenario 

The scenario selected was a typical radiology session, with acquisition of scheduled exams on CT and / or MR 
Scanner, consultation of previous relevant exams information on workstations associated to image sources, reporting 
of exams on an interpretation station and archiving of interpreted exams following pathology related archiving rules. 

This scenario leads to implementing the kernel MIMOSA mechanisms for managing data movements between 
acquisition sources, interpretation workstations and the central archive. These mechanisms cover the major image 
management functions required for ensuring the availability and timely access to relevant information: 

• prefetching of previous relevant examination information, 

• preloading of exams to be interpreted, 

• archiving of exams following site specific rules. 

Working flows and associated data movements are ordered in accordance with scheduling information sent by the 
local Radiological Information System (IRIS). 

5.2.3.1 .1 . Data flow diagram and the chronology of associated events 

Figure 2.3.1-1 depicts the complete scenario data flow and the associated chronology. This scenario will be fully 
implemented in the 1995 demonstrator. The 1994 prototype includes the major mechanisms on which the demonstrator 
will be based, in terms of data management, image copy mechanism and functional interfaces. 
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figure 2.3.1-1 Scenario dataflow diagram and associated chronology 
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(2) Retrieval of previous radiological reports and transmission of scheduled exams 

(3) Prefetching of previous archived exams to the workstation associated to the image source 

(4) Exams to acquire 

(5) Request of additional historical images 

(6) Additional historical images 

(7) Examination realisation 

(8) Importation of a new exam 

(9) Prefetching of previous archived exams to the reporting workstation 

(10) Preloading of new exams to the reporting workstation 

(11) Request of additional historical images 

(12) Additional historical images 

(13) Examination Reporting and report dictation 

(14) End for reporting session, transmission of reported exams 
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(16) Transmission of dictated report to secretaries 

(17) Report typed in the RIS 

(18) Report + Pathology 
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5.2.3.1.2. MIMOSA Functions involved in the scenario 

Basic MIMOSA Functions will be implemented in the MIMOSA kernel, being: 

• Acquisition Preparation, 

• Reporting Preparation, 

• Data Availability Management, 

• Data Consultation, 

• New Image Management, 

• Report Management. 

Table 2.3.1-2. gives for each step the MIMOSA functions involved in the scenario. 

5.2.3.1.3. MIMOSA Data Concepts used in the scenario 

Basic MIMOSA Data Concepts will be implemented in the system database, being: 

• Patients, Examinations, Clinical Requests, Examination Steps, Image Objects, as part of the Examination 
Context Related Data. 

• Platforms, MIMOSA Directories, Object Copies and Availability Requests as part of the MIMOSA 
Management Related Data. 

5.2.3.2. User Interface requirements 

Some specific requirements are related to user interaction with the system. All these interactions are summarised in 
figure 2.3.2-1, that depicts the user screens corresponding to the Data Consultation Queries and 
Acquisition / Reporting Worklists Manipulation. This User Interface will be fully available in the 1995 Demonstrator 
as a minimum requirement for a clinical routine usage. Only a subset of these functions is available in the 1994 
prototype, in particular only minimum data selection / sort criteria are accessible. 

5.2.3.3. Site environment and associated constraints 

The current MIMOSA prototype is integrated in the Ethernet-base SIRENE II PACS. In this part, the main outlines of 
the SIRENE PACS are presented, and the constraints resulting from this integration are listed. 

Global architecture of the SIRENE II PACS : 

• The SIRENE II PACS is in routine operation since 1991. It is currently working as an "examination router"; it means 
that its function consists of acquiring the digital images from the digital modalities and communicating them to a 
number of client applications supported by dedicated workstations. In particular it does not fulfil archiving functions 
which remain under the responsibility of the client applications. Such capabilities are satisfactory for PACS 
applications related to surgery planning. Actually in such applications the added value arises from the digital nature of 
images, allowing image processing to be performed with optimal accuracy (delineation of anatomical structures, target 
definition, 3D display, etc.). The utilisation of PACS in diagnostic radiology is very interesting, but more complex to 
implement since the added value partly arises from the availability to the user of previous exams at the various stages 
of image production and utilisation. This problem is addressed in the MIMOSA model which provides original 
concepts and solutions (availability level, MIMOSA directory, data availability manager, RIS interoperability). 

• The general architecture of the SIRENE II PACS system is depicted on figure 2.3.3-1. The system is installed at the 
Pontchaillou hospital and connects various kinds of equipment distributed in 5 departments: 

the radiology department 

the neurosurgery department 

the Cancer Centre 

the SIRENE central site 

the SIM laboratory, at the Faculty of medicine. 

It is a multi -vendor PACS : eight imaging equipments are currently connected, namely: 

3 CT: a SOMATOM-PLUS (SIEMENS) and a CT-PACE (GEMS), located in the radiology department, 
and another CT-PACE (GEMS) at the Cancer Centre, 

1 MR: MR-MAX (GEMS), located in the radiology department (separate building), 

2 DSA: DSI (PHILIPS), located in the radiology department, 

1 3D angiography system: 3D morphometer (GEMS), located in the radiology department, 
1 MEG: MAGNES (BTI), located in the radiology department. 



— 83 — 



— MIMOSA Prototypes — 



— 84 — 



— MIMOSA Prototypes — 



Function of the scenario 


Explanation 


MIMOSA functions 
involved 


Actor involved 
Implementation 


(1) Examination Scheduling 


Entering of a clinical request in 
the RIS 


OUT of MIMOSA 


Secretary 
RIS 


(2) Retrieval of previous 
radiological reports 
and transmission of 
scheduled exams 


RIS retrieves the patient's previous 
exams and sends to the IMS the 

list of exams to be performed 
together with the previous reports 


OUT of MIMOSA 


RIS 


(3) Prefetching of previous 
archived exams to the 
workstation associated to the 
image source 


Upon reception of the list of 
exams to be acquired the IMS 
sends the previous reports to the 
reporting workstation which will 
be used, together with images if 
those images have been archived 
(patients entering in a application 
protocol) 


Acquisition Preparation 
Data availability 
management 


IMS 

Workstation ass. to Image 
source 


(4) Exams to acquire 


The IMS sends to the workstation 
associated to the image source the 
worklist of the exams to be 
acquired 


Acquisition preparation 


IMS 

Workstation ass. to Image 
source 


(5) Request of additional 
historical images 


During the acquisition the 
radiologist wants to access to 
additional images concerning the 
patient 


Data consultation 


IMS 

Workstation ass. to Image 
source 


(6) Additional historical images 


The requested images are sent to 
the requester 


Data consultation 


IMS 

Workstation ass. to Image 
source 


(7) Examination realisation 


The examination is performed on 
the imaging device 


OUT of MIMOSA 


Imaging Device 


(8) Importation of a new exam 


The image data produced during 
the examination are sent to the 
IMS. 

The IMS stores them in its 
temporary storage area 


New image management 
Data availability 
management 


IMS 

Imaging Device 


(9) Prefetching of previous 
archived exams to the 
reporting workstation 


Upon reception of the list of 
exams to be reported the IMS 
sends the previous reports to the 
reporting workstation which will 
be used, together with images if 
those images have been archived 
(patients entering in a application 
protocol) 


Reporting Preparation Data 
availability management 


IMS 

Reporting Workstation 


(10) Preloading of the newly 
acquired exams to the 
reporting workstation 


The IMS sends the new exams to 
the workstation(s) which are likely 
to be used for the examination 
reporting 


Reporting preparation Data 
availability management 


IMS 

Reporting Workstation 


(11) Request of additional 
historical images 


During the reporting session the 

radiologist wants to access to 
additional images concerning the 
patient 


Data consultation 


IMS 

Reporting Workstation 



— 85 — 



— MIMOSA Prototypes — 



(12) Additional historical images 


The requested images are sent to 
the requester 


Data consultation 


IMS 

Reporting Workstation 


(13) Examination Reporting and 
report dictation 


The radiologist interprets the exam 
and dictates the report 


OUT of MIMOSA 


Radiologist 
Reporting Workstation 


(14) Transmission of reported 
exams 


The data produced during the 
interpretation session are sent to 
the IMS (status "interpreted", 
selection of the most relevant 
images, eventually report in digital 
form) 


Report management 


IMS 

Reporting Workstation 


(15) Selection of images to be 
copied on film 


The radiologist selects the images 
to be printed, which are sent to the 
laser printer 


OUT of MIMOSA 


Radiologist or technician 
Reporting Workstation 
Hardcopy system 


(16) Transmission of the dictated 
report to secretaries 


The tape containing the dictated 
report is brought to secretaries 


OUT of MIMOSA 


Radiologist or technician 
Secretary 


(17) Report typed in the RIS 


The secretary types in the report in 
the RIS, (including eventually an 
indication on pathology, 
determining whether the 
patient/exam should enter in a 
specific application protocol) 


OUT of MIMOSA 


Secretary 
RIS 


(18) Report + Pathology 


The report is sent to the IMS 
together with an indication on 
pathology 


Report management 


RIS 
IMS 


(19) Archiving / Deletion 


According to an indication on 
pathology, and according to data 
management rules a storage 
strategy is decided: 

- if the patient and exam enter into 
one of the application protocols 

the exam data are archived 

- if not, the data are kept during a 

certain period of time, then 
automatically deleted by the 
system 


Report management 
Data availability 
management 


IMS 



table 2.3.1-2 : Scenario steps and involved MIMOSA functions 
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Workstations are distributed in the previously listed departments: 

1 DATA VIEW workstation (GEMS), 1 EASY VISION (PHILIPS), and 2 Advantage Windows (GEMS) in 
the radiology department, 

1 PC Workstation (TSI-I-Lab) and 1 Advantage Windows (dedicated to surgery planning), in the 
neurosurgery department, 

several radiotherapy planning workstations (GEMS) at the Cancer Centre. 

The IRIS Radiology Information System is connected to the PACS. 

The system manages about 2000 images a day (about 1 Gigabyte of data). 

• The principle of the operation of the SIRENE II system is presented figure 2.3.3-2: it shows 3 kinds of components: 
Import daemons are responsible for receiving the images from the digital modalities; images are put in 
containers and transmitted to the Dispatch spooler. Information about the scheduled examinations are also 
transmitted to the PACS by means of an Import daemon. 

The Dispatch Spooler is responsible for routing the images to the appropriate client applications ; by default, the 
selection of those applications is performed according to rules defined by the radiologists and based on the 
characteristics of the examinations (examination type, requesting clinician, requesting department, etc.): however, 
key-words may also be entered by the technicians to indicate an explicit destination; these key-words are entered 
in comment fields related to the examinations. The actual transfer to the client applications is managed by Export 
Spoolers. 

Export spoolers are responsible for the actual transfer of the images to the client applications (e.g. Advantage 
Windows workstation of a given radiologist, platforms supporting surgery planning procedures). Export spoolers 
also convert the data to the specific image format used by the client application. Flow control allows the transfer 
to be delayed, if the application is not able to receive the data (e.g. station not connected or no space available). 

The system has its own administration mechanisms, allowing the activity to be controlled and monitored, and statistics 
to be obtained on activity. 

The system is based on a home-made CASE tool called SNOOP. SNOOP is an Object Oriented software platform 
suited for the rapid and efficient prototyping of multi-tasking applications. It is basically an extension of the UNIX 
command interpreter (shell). It consists of a class hierarchy and development tools. The former contains primitive 
classes (e.g. string, integer, Boolean) and composite classes (e.g. demaon and spooler). SNOOP offers the basic object 
oriented mechanisms like inheritance, polymorphism, overloading, encapsulation, and instance creation. 

General constraints : 

A major constraint arises from the fact that the PACS is used in routine, so the introduction of new components and 
new capabilities must not disturb the routine operation of the system. Some routing mechanisms offered by the present 
system will be able to be moved on the MIMOSA system. However, it is not planned in the short term. It has been 
preferred to integrate the MIMOSA system in a stepwise way, allowing risks to be minimised. So, only a subset of 
SIRENE II imaging components is involved in the scenario and interfaced with MIMOSA functions: 

CT image source : 

. Type " : SOMATOM PLUS - S (SIEMENS) 
. Hardware : Micro VAX + SUN (gateway) 
.Software : SOMARIS/2 
. Interface constraints: 

• The interfacing of the SOMATOM to the SIRENE II PACS is in operation since 1993. It involves a 
dedicated gateway based on a SIEMENS proprietary protocol implemented on a SUN workstation, which 
allows images to be sent to the SIRENE II PACS, via a dedicated import daemon. 

• It is obviously not possible to implement the access to MIMOSA services directly on the CT platform. 
Consequently, the management of worklists and the user interaction on the one hand, and the management 
of acquired images on the other hand, will have to be managed on complementary platforms (namely the 
Consultation workstation associated to the SOMATOM, and the PACS server, respectively). 

Consultation workstation associated to CT source: 

. Type : Advantage Windows Workstation (GEMS) 

. Hardware : SUN SPARCstation 10 

. Software : Advantage Windows Version 1.2 

. Interface constraints: 

• This workstation is a GEMS product, and it is critical for the site evolutivity that the MIMOSA image 
management capabilities (e.g. worklists management) can be offered to the users while continuing using a 
"standard" (i.e. non specific) Advantage Windows platform. This is possible thanks to the "open" 
philosophy of the Advantage Windows platform, which allows a high level of interworking with external 
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figure 2.3.3-2 : Principle of the SIRENE II PACS : an examination router 



— 90 — 



— MIMOSA Prototypes — 



• The Advantage Windows platform implements two mechanisms for importing images: a first possibility 
consists in putting images in an "import directory", the second is based on the DICOM standard: the 
platform implements the STORE Service Class (it is provider of the service). 

• The users of this workstation will primarily be the technicians in charge of the acquisition of CT 
examinations on the SOMATOM equipment. However, internists and radiologists will also use this platform 
to display the previous relevant exams and reports related to the examinations being acquired. 

MR image source : 

. Type ' : MRI MRMAX (GEMS) 

. Hardware : Proprietary + DATA VIEW workstation (gateway) 
.Software : DAT A VIEW Ver. 05.00 
. Interface constraints: 

• The interfacing of the MRMAX to the SIRENE II PACS is in operation since 1991. It involves a dedicated 
gateway based on the DATAVIEW (GEMS) workstation, which allows images to be sent to the SIRENE II 
PACS, via a dedicated import daemon. 

• It is obviously not possible to implement the access to MIMOSA services directly on the MR or 
DATAVIEW platforms. In the short term, only the acquisition of the MR images will be managed in the 
MIMOSA system. The addition of a consultation workstation at the MRMAX site is not possible in the 
short term, for technical and organisational reasons. 

Reporting workstation : 

. Type : Advantage Windows Workstation (GEMS) 

. Hardware : SUN SPARCstation 20 

. Software : Advantage Windows Version 1.2 

. Interface constraints: 

• The interface constraints are similar to those concerning the Consultation workstation associated to the 
SOMATOM. 

• The users of this workstation will primarily be the radiologists in charge of the reporting of the CT or MR 
examinations acquired on the SOMATOM or MR-MAX systems. The application shall provide worklists 
management, as well as the facilities to access the previous exams and related reports: while the consultation 
of images will be offered by the MIMOSA kernel, radiological reports will be accessed directly by the 
application (at least in the short term). 

Central Storage System : 

. Type : SIRENE II PACS central server 

.Hardware : SUN SPARC Center 2000 + HP jukebox; 

. Software : SNOOP based PACS application 

Dorotech migration package 
. Interface constraints: 

• Several storage areas (MIMOSA directories) will be implemented on the Central Storage System. Magnetic 
disk storage areas are accessible by means of standard UNIX commands. Access to the jukebox (100 
Gbytes) can be done through the "Migration" software package (Dorotech): it allows the specifics of the 
MOD jukebox to be managed in a transparent way (migration units are accessed as conventional UNIX files 
by the application). The configuration of the system consists in defining the migration units (size of the 
magnetic cache, number of MOD media, etc.). 

RIS system : 

. Type : IRIS Radiology Information System 

. Hardware : MAC Server (VX 24/230) and 6 MAC Clients (connected via Ethernet) 

. Software : Home-made software based on the 4D software package (ACI) 

. Interface constraints: 

• The Scheduled examinations are sent to the PACS server through Ethernet: it allows the previous relevant 
examinations to be retrieved, and the previous radiological reports to be accessible to the reporting 
workstations. Once the reports have been transcribed, they are transmitted to the PACS server to be 
accessible to reporting workstations. All these data are received by the RIS import daemon of the PACS 
server. 

• Communication between IRIS and the PACS server is uni-directional. 

• The IRIS server should be implemented on a UNIX platform in the near future, which should facilitate 
interworking in the future (e.g. utilisation of standards protocols such as DICOM). 
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5.2.4. Key characteristics 

5.2.4. 1. Main functional features 

5.2.4.1.1. Exam step scheduling 

A new exam step is scheduled every time the Radiological Information System IRIS sends a request for a new exam. 
The scheduling of exam steps (Acquisition and Reporting Steps) results in updating users' Worklists where: 

• Worklist entries are created in compliance with the scheduling information (who, what, when) sent by the 
Radiological Information System IRIS. 

• Worklist entries are updated according to acquisition and reporting step status changes (scheduled, started, 
completed, ...). 

• Modification of scheduling information (under IRIS responsibility) or updating of some patient or exam 
attributes are reported in the worklists (available in 1995 demonstrator). 

5.2.4.1.2. Image flow and data storage management 

Particular attention has been paid to this major feature, which is the key for timely access to image. The availability of 
data on the different MIMOSA Directories (prefetching) is triggered by scheduling events, acquisition and importing 
events, according to configurable criteria. 

Migration between various directories (data exchange between different data stores) is managed through the 
"Availability Management" concept, which is a logical description of the overall system in terms of "inter-repository 
distance" and data throughput and allows the implementation of generic mechanisms, independent of the real physical 
architecture. 

The main data repositories managed by the system are: 

• a short term central storage (day_storage), 

• a mid term central storage (week_storage), 

• a long term central archive (central_archive), 

• a temporary storage located near the acquisition workstation {acqui_ remote_storage), 

• a temporary storage located near the reporting workstation {report_ remote _storage), 

Each of these repositories is manipulated through a generic functional interface, offering (at least) the following 
functions: 

• the ability to move data copies between MIMOSA Directories, 

• the ability to delete data copies, 

• the ability to import data copies from external address, 

• the ability to export data copies to external address, 

• the ability to manage the data repository (status tracking, available space managing, ...). 

5.2.4.1.3. Exam context object creation 

A new Patient is created in the database, 

• every time an exam is scheduled, which concerns a patient not already declared in the database, 

• every time a foreign exam is imported, that is related to a patient not already declared in the database. 

A new Clinical Request is created in the database, 

• every time an exam is scheduled, which is associated to a clinical request not already declared in the 
database. 

A new Exam is created in the database, 

• every time the Radiological Information System IRIS sends a request concerning an exam that is not already 
declared in the database, 

• every time a foreign exam is imported in the system. 

5.2.4.1.4. Image acquisition 

The Image acquisition function consists of getting new images from the acquisition sources, associating them with 
Acquisition Steps, storing the data on a secured data store and triggering the availability of copies, according to 
configurable criteria. 
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5.2.4.1.5. Image consultation 

The Image consultation function permits browsing of the Patients / Clinical Request / Exams / Images database and 
also exporting selected Image Objects. 

5.2.4.1.6. Exam report 

This function permits entering in the system a new report associated with a Reporting Step. 

The entering of a new report triggers the archiving of associated exam data according to configurable rules. 

5.2.4.2. The global functional architecture 

The global functional layout of the Prototype is depicted in figure 2.4.2.-1. 

5.2.4.2.1. The site-independent functional kernel 

The MIMOSA functional kernel is derived from the MIMOSA functional model. Only a subset of MIMOSA functions 
has been implemented. These functions were selected for their relevance with respect to the objectives of the 
prototype. 

Figure 2.4.2-2 depicts the global functional architecture of the MIMOSA kernel. 

5.2.4.2.2. The functional Adaptation Layer 

The functional Adaptation Layer consists of three types of Adapter. 

An Acquisition Adapter is responsible for the functional and data model adaptation between the MIMOSA kernel, and 
non MIMOSA compliant Images Sources and Acquisition Workstations 

A Reporting Adapter is responsible for the functional and data format adaptation between the MIMOSA kernel and 
non MIMOSA compliant Reporting Workstations. 

A RIS Adapter (also called the Act Management System Emulator) is responsible for building, ordering and delivering 
MIMOSA compliant Acquisition / Reporting Requests according to the messages received from the IRIS system. 

5.2.5. Design 

5.2.5. 1. Abstract services and data flow diagrams 

The following description concerns both the 1994 Prototype and the 1995 Demonstrator. Data Flow Diagrams include 
Security Management Functions, although these functions are not implemented in the 1994 Prototype. 

Sessions Management (figure 2.5. 1-1) 

This function aims at creating and maintaining client session contexts. 

Acquisition Preparation (figure 2.5.1-2) 

This function processes the acquisition request sent by the RIS Act management System. 

• It ensures the availability of the previous relevant examinations mentioned in the clinical request. 

• It provides the client acquisition applications with the mechanisms allowing them to build Acquisition Steps 
worklists, and to get information related to those Acquisition Steps. 

Reporting Preparation (figure 2.5. 1-3) 

This function processes the reporting request sent by the RIS Act Management System. 

• It ensures the availability of the examination to be reported as well as other relevant examinations associated with 
the scheduled Reporting Step. 

• It provides the client reporting applications with the mechanisms allowing them to build Reporting Steps 
worklists, and to get information related to those Reporting Steps. 
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figure 2.4.2-1 : MIMOSA Rennes prototype functional layout 




figure 2.4.2-2 : MIMOSA Rennes prototype kernel functional architecture 




fig. 2.5.1-1 Sessions Management External Data Flows 
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fig. 2.5.1-2 Acquisition Preparation External Data Flows 
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fig. 2.5.1-3 Reporting Preparation External Data Flows 
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Data Availability Management (figure 2.5. 1-4) 

This function ensures availability of data to users and importing / exporting data to / from users, in response to 
requests sent by other MIMOSA internal functions. 

• It is responsible for managing creation of data copies in the MIMOSA data storage (by duplicating existing data 
or importing new data), migration of data copies between data storage, deletion of copies no longer necessary, 
export of data copies. 

Data Consultation (figure 2.5. 1-5) 

This function manages access to the images and related information for the user. It is primarily oriented towards 
consultation of results as opposed to the consultation of all entities stored in the MIMOSA database (such as, for 
instance, scheduled Acquisition Steps). 

• It allows lists of Patients, lists of Clinical Requests, lists of Exams and lists of Image Objects to be consulted, 
according to various selection criteria. 

• It allows all characteristics of a selected Patient, Clinical Request, Examination to be retrieved. 

• It allows the Examination associated Report to be returned. 

• It allows Image Object copies to be exported to a MIMOSA external destination. 
The "View On Patient Record" concept is not implemented in 1994 Prototype. 

New Images Management (figure 2.5. 1-6) 

This function processes the Image Object import requests for a newly performed Acquisition Step. 

• It gives to the Data Availability Management function the responsibility of choosing the MIMOSA data storage 
into which Image Objects will be imported, and to manage the actual import of the objects. 

• It informs the RIS Act management System of the completion of the Acquisition Step, and generates Availability 
Requests to preload the data for future use. 

New Reports Management (figure 2.5. 1-7) 

This function receives the report produced during a Reporting Step, enters it and the related information in the 
MIMOSA database, informs the RIS Act Management System of the completion of the Reporting Step and generates 
Availability Requests to preload the related data for future use and / or archive them. 

Acquisition Adaptation 

This function provides the acquisition sources and associated workstations with services to adapt to MIMOSA: 

• It retrieves from the MIMOSA System the information needed for building the acquisition worklist, and permits 
the selection of a particular exam to be acquired. 

• It requests the export of previous relevant Exams. 

• It provides browsing facilities to retrieve previous examination results stored in the MIMOSA system. 

• It buffers newly acquired images and requests to the MIMOSA System for import of the completed image series. 

• It eventually asks the RIS Act Management System to generate a Reporting Request, as a result of an explicit 
demand expressed by the performer of the examination. 

Reporting Adaptation 

This function provides the reporting applications with services to adapt to MIMOSA: 

• It retrieves from the MIMOSA System the information needed for building the reporting worklist, and allows the 
selection of a particular exam to be interpreted. 

• It requests the export of the Exam to be reported and of previous relevant Exams. 

• It provides browsing facilities to retrieve previous examination results stored in the MIMOSA system. 

• It informs the MIMOSA System of the completion of the Reporting Step. 

• It enters the new reports in the MIMOSA system. 

Act Management System Emulation (RIS Adaptation) 

This function provides the local Radiological Information System with services to adapt to MIMOSA: 

• It processes the list of scheduled examinations sent by the local RIS, in order to generate the suitable Acquisition 
and Reporting Request to be sent to the MIMOSA System. 

• It processes the "Acquisition Completed" and "Reporting Completed" messages sent by the MIMOSA System. 

Storage Management 

This function aims at processing the Import, Move, Export and Delete Commands sent by the Data Availability 
Management Function. 
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It is responsible for managing the various MIMOSA Directories (distributed storage and archiving system). 
It is responsible for importing data from external MIMOSA platforms. 
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fig. 2.5.1-4 Data Availability Management External Data Flows 
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fig. 2.5.1-5 Data Consultation External Data Flows 
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• It is responsible for exporting data to external MIMOSA destinations. 

5.2.5.2. Administration, configuration and monitoring functions 

According to the aims of the 1994 Rennes prototype, only basic mechanisms for administrating, configuring and 
monitoring the overall system are being implemented. 

Particular attention will be paid to the improvement and enrichment of these mechanisms during 1995, in order to 
reach a high level of manageability and security for the 1995 demonstrator, allowing it to be used in clinical routine. 

5.2.5.3. Logical design: the subsystems 

The overall system consists of following interrelated logical subsystems (see figure 2.5.3-1): 

- Adaptation Subsystem: 

Act Management System Emulator (RIS Adapter) 
Acquisition Adapter 
Reporting Adapter 

- MIMOSA Interface Subsystem: 

Application Access Layer 

- Communication Layer: 

Communication stacks 

- Workflow Management Subsystem: 

Internal Worklists Manager 
Operation Preparation 

- Data Flow Management Subsystem: 

Data Availability Manager 
Data Migration Manager 

- Data Storage Subsystem: 

Data Storage Access Server 
Data Storage 

- Data Access Subsystem: 

Data Consultation Manager 

- Database Subsystem: 

Database Manager 

- Configuration Subsystem: 

Configuration file Access 

- Administration Subsystem: 

Site Administrator 
Administration Entities 

5.2.5.4. Organisational design 

Major organisational choices are the following: 

• the use of client / server paradigm, 

• a system based on a central server (MIMOSA server) and distributed adaptation components, 

• a distributed set of data managed by the MIMOSA server through a central data storage server. 

5.2.5.5. Data base design 

Database server and distributed configuration files 

The various data derived from the MIMOSA data model have been organised in four domains: 

• exam context data, 

• image data, 

• image management data, 
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system configuration data. 
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figure 2.5.3-1 : Global Logical Architecture Layout 
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Data schema grouping and normalisation 

A formal transformation of the conceptual data model resulted in a normalised model consisting of: 

• a list of information classes, 

• a description of each information classes in terms of attributes, 

• a description of associated constraints. 

This "grouped data schema" permitted the generation of the MIMOSA Server Informix® Database. 

5.2.5.6. Generic kernel design - a DICOM compatible approach 

Particular attention has been paid to the openness of the system. The major external interfaces have been specified by 
considering their ability to be implemented in terms of DICOM services (Storage, Query / Retrieve, Study 
Management, Patient Management Service Classes). Figure 2.5.6-1 depicts the global architecture resulting from this 
approach. For a more complete discussion concerning the relations between DICOM et MIMOSA, refer to chapter 4 
of this document. 

5.2.5.7. The MIMOSA kernel Access Library 
Why an Interface Library? 

It was a requirement that the major services offered through the MIMOSA kernel Access Library were defined in 
accordance with DICOM specifications. Even though the first revision of this Library is not built on top of DICOM 
communication layers, it was designed to be portable in a full DICOM environment with minimum adaptation. In 
particular it is compatible with the communication logic of DICOM protocol, based on associations, request / answers 
and events. 

In this first implementation, emphasis was placed on functional exchanges between the MIMOSA kernel and its 
environment. In this context, defining a well defined Client Application Programming Interface was required in order 
to develop portable software. This preliminary functional-oriented integration was the first step toward the 
development of an open MIMOSA kernel. It will be followed in 1995 by the integration of DICOM communication 
components. This will demonstrate how it is possible to base the exchange between a MIMOSA kernel and its 
environment on DICOM communication services. 

This approach allows for a smooth migration to a DICOM compatible interface, without enforcing the use of DICOM 
in the earlier implementations. 

Library overview - the major services 

Major services offered by the MIMOSA kernel Access Library through its Application Programming Interface are: 

• the ability to schedule Acquisition and Reporting Steps, 

• the ability to receive scheduling events from the MIMOSA server, 

• the ability to consult Patients, Clinical Requests, Exams and Image Data, 

• the ability to import / export images to / from MIMOSA server, 

• the ability to receive import / export events from the MIMOSA server. 
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fig. 2.5.6-1: MIMOSA Kernel Global Architecture Layout 
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5.3. MIMOSA Implementation at 
Luxembourg 

Paragraph 5.3.1. presents the main objectives of the prototype developed at Luxembourg. The paragraph 5.3.2. 
explains how the prototype was realised, from the specifications to the experimental work. The paragraph 5.3.3. 
describes the specification of the prototype in terms of: scenario, users requirements and constraints associated with 
the site. The key characteristics of the prototype are defined in paragraph 5.3.4. in terms of features, data and 
architecture. The overall system architecture is described in paragraph 5.3.5. The experimental results and experience 
gained are presented in paragraph 5.3.6. 

5.3.1. Objectives 

The Luxembourg prototype implements that part of the MIMOSA model which can be used to describe an application 
for teleradiology, based on a MIMOSA kernel. 

The objective was to demonstrate the feasibility of another implementation of the MIMOSA model and to assess the 
ability of the MIMOSA model to cope with a specific scenario as encountered at the Hospital of Luxembourg for 
teleradiology. 

A link exists between MIMOSA and the IMPHONE topics such that teleradiology operations could be demonstrated 
between implementations made by the two topics. This co-operation showed the interoperability of different 
applications using the MIMOSA kernel. 

5.3.2. Methodology 

5.3.2.1. Basic inputs 

To begin with, the clinical scenario covered by the prototype was specified. After having designed the overall system 
from a user viewpoint, correspondence was drawn up with the MIMOSA model. The MIMOSA functions involved in 
the scenario and the MIMOSA data concepts to be manipulated were identified. 

5.3.2.2. Site environment and constraints 

The developments were of two types: 

- site-independent developments which correspond to the MIMOSA kernel, 

- site-specific developments which correspond to the client application. 

The client application calls functions of the MIMOSA kernel and is interfaced with existing components of the site 
(the Radiology Information System and various modalities). 

5.3.2.3. The overall system analysis and design process 

The MIMOSA kernel and the teleradiology client application were developed concurrently in 1993 and integrated 
together at the end of that year. Firstly the scenario and the functions of the prototype were determined. The user 
interface of the client application was defined and a first version of the graphic interface realised. Then the client 
application was designed, coded and tested, independently of the MIMOSA kernel. When the client application was 
completely tested, it was integrated with the MIMOSA kernel. At the beginning of 1994, a functioning version of the 
overall system was obtained. 

Then some improvements to the application were initiated. The user interface was made more user-friendly. The 
application was coloured in a gray scale, and some buttons were replaced by icons. Moreover prototype functions were 
extended: the possibility of sending a patient folder extract was added to the application. 
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5.3.2.4. Experimental work 

The prototype was tested with different methods of communication between Luxembourg and different sites, using an 
ISDN link with General Electric at Paris (June 94) and using an Internet link with the IMPHONE topic at Pisa in Italy 
(October 94). A medical scenario was followed by radiologists in the exchanges between Pisa and Luxembourg. 

5.3.3. Scenario, requirements and constraints 

5.3.3.1. Scenario 

The scenario covered by the prototype was a typical exchange of advice requests, as depicted by the following diagram 
(figure 5.3.3.-1). 

The sending of an advice request consists in the selection of examinations on teleradiology workstation ([1], [2], [3]), 
the consultation of patient clinical data from the Radiology Information System ([4], [5]), the choice of the consulted 
radiologist, the dictating of the request and the sending of the request ([6]), with the clinical data or not. 

The sending of advice begins with the consultation of the received advice request ([7]). This consists in the display of 
the received examinations ([1]) and the consultation of the clinical data if sent. 

Then the consulted radiologist may decide to reply to this request and sends advice about the received examination 
([6]), together with new images ([2], [3]) if appropriate. 
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figure 5.3.3.-1: Scenario. 

This scenario led to the implementation of the MIMOSA kernel mechanisms for managing opinion requests. 

5.3.3.1.1. MIMOSA Functions involved 

Managing functions implemented in the MIMOSA kernel are: Data Consultation, Opinion Request Management and 
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Additional Image Management. 

5.3.3.1.2. MIMOSA Data Concepts used 

The MIMOSA Data Concepts implemented in the system database as part of the Examination Context Related Data 
are: Observation Description, Opinion Requests, Opinions, Health Care Professional and Examination. 

5.3.3.2. User interface requirements 

The user interface of the prototype is based on the interface of the PACS of the hospital of Luxembourg, LUXIMACS. 
Its ergonomics was validated by radiologists at the hospital. 

The following page (figure 5.3.3-2) contains the window for the creation of an advice request, to illustrate this 
interface. 

5.3.3.3. Site environment and associated constraints 

The MIMOSA prototype is interfaced with the Radiology Information System of the hospital of Luxembourg, which is 
an Oracle database. The teleradiology workstation is a SUN SPARC 10. It is connected to two modalities: a CT 
HiSpeed and a MR Signa and can access to ISDN and Internet (figure 5.3.3-3). 
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figure 5.3.3-3: Development environment. 



5.3.4. Key characteristics 



5.3.4. 1. Main functional features 



The prototype allows the exchange of advice requests between radiologists at the same hospital or at different sites. A 
radiologist can request the advice of another radiologist related to an examination to confirm a diagnosis or suggest an 
intervention. For instance, if the radiologist consulted has specialised 3D tools, a 3D reconstruction could be included 
in the images transferred. 

The advice request which is sent is composed of: 

- a patient folder extract, 

- a main examination, 

- additional examinations, 

- a free text which describes the context of the examination. 

The advice request relates to the main examination. Additional examinations can help the consulted radiologist to 
formulate advice more effectively. 

The patient folder contains clinical data which are read from the Radiology Information System of the hospital in 
Luxembourg. It includes information such as patient data, the history of the patient, therapy, family background, 
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characteristics of the examinations and of previous examinations sent, etc. 



CREATE OPINION REQUEST — Lysiane 



Em-IP ACS / MIMOSA 





Is there a tumour recurrence in the right lateral part of hypophysis ? 
The first image of the second serie looks suspect. 




Mimosa — Centre Hospitaller de Luxembourg " 



figure 5.3.3-2: Creation of an opinion request. 



5.3.4.2. The global functional architecture 

The global functional architecture of the prototype is depicted in the following diagram (figure 5.3.4.2-1). 
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gure 5.3.4.2-1: Global functional architecture. 



The basic functions of the MIMOSA kernel are used by the client application to manage opinion requests. The client 
application contains a set of functions to consult certain data in the Radiology Information System and to visualise 
examinations. 

5.3.4.3. Data architecture 



The implemented data model is derived from that part of MIMOSA data model describing communication between 
MIMOSA users. The following NIAM diagram (figure 5.3.4.2-2) depicts the relations between the main implemented 
data concepts: MIMOSA User, Examination, Opinion Request and Opinion. 



5.3.5. Design 

To realise the prototype, the MIMOSA kernel as implemented by General Electric was used and developments for 
teleradiology purposes were added to the Advantage Windows software. Advantage Windows is a product of General 
Electric which permits the display and processing of medical images. The client application was developed around the 
MIMOSA kernel in ANSI C, in a UNIX environment, with a graphic interface in Motif. The communication method 
used between two different European sites (Paris, Pisa) was European ISDN and Internet. It was interesting to 
implement a solution based on two different methods of communication because in the future, the hospital of 
Luxembourg will need to communicate with various interlocutors, for example: others hospitals and general 
practitioners. Some of them will certainly be connected to ISDN, the others to Internet. 

5.3.6. Experimental work 

5.3.6.1. EuroPACS, September 93 

A prototype was demonstrated in Rennes, during EuroPACS in September 93 (figure 5.3.6.1-1). Advice requests were 
exchanged between two Advantage Windows systems, on a local site. 
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gure 5.3.4.2-2: MIMOSA model for examination context: Opinion request. 
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figure 5.3.6.1-1: Rennes - EuroPACS. 



5.3.6.2. Paris, June 94 



A demonstration was performed at General Electric in Paris, in June 94 for the Commission (figure 5.3.6.2-1). The 
prototype allowed exchange of advice requests between the hospital of Luxembourg and General Electric, through an 
ISDN link. 

The hospital of Luxembourg and General Electric exchanged an advice request about a hypophysis tumour, and 
10 MR images (256 x 224, about 1,5 Mo) of the examination were sent in about 3 minutes. 
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igure 5.3.6.2-1: Communication between Luxemburg and General Electric. 

5.3.6.3. Pisa, September 94 

An evaluation is being performed between Pisa in Italy and Luxembourg (figure 5.3.6.3-1). The IMPHONE topic in 
Pisa developed a teleradiology prototype using the same MIMOSA kernel, but on another platform. As some functions 
of the two prototypes (Pisa and Luxembourg) are similar, it is possible to create an advice request in Pisa with the 
IMPHONE prototype and send it to Luxembourg. The MIMOSA prototype in Luxembourg can read it and reply, and 
vice-versa. Therefore, it is interesting to show that two different applications, each developed around the MIMOSA 
kernel, are able to communicate. 

The hospital in Pisa does not have a direct ISDN link, therefore the way of transfer between the two sites is Internet. 
As there is no Internet link at the hospital of Luxembourg, in a first instance, the connection was established with the 
Public Research Center Henri Tudor. Sending advice requests directly from the hospital of Luxembourg is foreseen as 
soon as a link (64 kbits/s) is installed between the Center Henri Tudor and the hospital. 
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gure 5.3.6.3-1: Communication between Luxemburg and Pisa. 

A scenario for a clinical evaluation is being made by Dr Kurdziel of Luxembourg and Dr Caramella of Pisa, both of 
whom are radiologists. The evaluation consists in testing the medical scenario previously defined by the two 
radiologists (figure 5.3.6.3-1). Dr Kurdziel will send an advice request about MR prostate images to Dr Caramella. Dr 
Caramella will give his advice about this examination to Dr Kurdziel. If Dr Kurdziel agrees with Dr Caramella, the 
discussion is finished. Else Dr Kurdziel will send a complementary advice request and Dr Caramella will reply to him, 
and so on. 
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figure 5.3.6.3-1: Medical scenario. 
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The purpose of the EurIP ACS-MIMOSA topic was to provide a generic framework for an information system dealing 
with the exchange and the management of medical images within a medical information processing organisation. This 
framework is claimed to be application and implementation independent, and comprehensive so as to include all the 
main facets of biomedical image handling, both computer and paper based. 

Thus, a Medical Image Management System built according to the MIMOSA specifications (called a MIMOSA 
system), can be considered as a processor located within imaging departments. MIMOSA exchanges data and offers 
services to its environment composed of medical image users. The MIMOSA system copes with the nature of 
exchanged data, the nature of offered services, the way how services are requested or performed and the way that data 
are received, processed and sent onwards. 

As an image management system is complex, a method is required to verify that it satisfies users' requirements before 
implementation. Such a method cannot be based on real programming languages as they force the specifications of 
implementation details and hide the main features of the system which cannot be properly addressed. 

To analyse such a system, and to deal with its complexity, the system must be abstracted. The purpose of the 
modelling process is to support the abstraction which isolates important aspects, relevant for the system use, and 
suppresses non essential details. Consequently, the MIMOSA topic proposes a general model, independent of 
specialities, organisations and implementations. Moreover this model has been designed with a prospective viewpoint, 
which means that the model takes into account how images are likely to be managed in the future rather than being 
restricted to how they are managed today. 

The prototype mainly aims at verifying that developer and user views match, and at demonstrating the relevance of the 
conceptual model. Finally the prototype indicates that the conceptual model, and the understanding of users' 
requirements are correct and detailed enough to enable such an information system to be really implemented. 

Since a major goal of the MIMOSA system is that of openness, the implementation of MIMOSA system should use 
existing standards as much as possible, both official and industrial. The existence of standards influences, to a certain 
extent, the definition of the architecture of the system, within which are built the tools required to ensure the 
interoperability of a MIMOSA system with other systems, such as acquisition, user workstation, and departmental 
information systems. 



6.1. Related work 



In addition to these intra-EurlPACS activities, co-operation with other groups focusing on the management of the 
Patient Record (such as GEHR, RICHE and NUCLEUS) has been investigated. 

- MIMOSA focuses on image management issues while remaining very close to end users requirements. This latter 
constraint led the topic group to consider concepts and functions of the system which are not really specific to the 
medical image domain but which are bound with the acquisition and utilisation of imaging examination, with the 
links between clinical requests and with the need for end users to access non-image clinical data during the 
acquisition, processing, reporting and consultation of images. The concepts of act and act management 
introduced by the groups working on the management of the patient record provide a general solution to take into 
account related concepts and functions. 

- Projects working on the Patient Record aim at defining general mechanisms allowing the organisation of the 
Patient Record and the customisation of the access to be offered to end users. Medical imaging presents 
additional difficulties principally related to the high volumes of image data and to their complex structure. The 
management of these data was the goal of MIMOSA modelling work. 

The comparison, mapping, and integration between MIMOSA and systems for handling patient records should be 
continued in order to improve the interoperability between image management and patient record management. This 
should lead to the refinement and the extension of both models, in order to obtain a common architecture. This 
architecture should contribute to the emergence of globally integrated information systems enabling the circulation of 
medical information inside and between health care organisations, a major aim proposed.. 



6.2. The MIMOSA model 



Before modelling could start, it was essential to agree upon a common terminology in order to ensure that users and 
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model designers share a common understanding of the real world to be modelled. In order to reach a sufficient level of 
generality, it was necessary to define the universe of discourse regarding the user manipulating images, scenarios 
concerning the handling of images from a user's viewpoint and the data involved. Collaborators in a number of 
European medical institutions were consulted during this review phase. 

The delineation of the domain covered by the MIMOSA model raised two difficulties: 

The first difficulty relates to the definition of the border between image management and medical imaging 
applications. Rather than addressing the details of all possible applications, the model provides general data structures 
and access functions. This allows applications to get appropriate and understandable information from MIMOSA and 
to provide MIMOSA with image information as produced by them. 

The second difficulty relates to the interface between MIMOSA and administrative and Departmental Information 
Systems (DIS), such as HIS-RISs. All the data and functions involved in image production and utilisation which we 
have encountered through users' contacts have been identified. Some of these functions have been modelled in detail in 
MIMOSA. The detailed modelling of the others falls outside the scope of MIMOSA. Nevertheless, all these functions 
and data structures can be implemented in different subsystems which must operate in an open system architecture so 
as to guarantee interoperability. 

The conceptual model describing the nature of biomedical images, their role in diagnosis, therapy, research and 
teaching, their dynamics and the operations involved in their handling has been specified. It has resulted in a general, 
detailed and verified conceptual model of data, functions and dynamics. 

The data model includes three loosely coupled parts: 

- The first part describes the general context of the production and utilisation of images (the examination context 
model). This part of the model defines the information entities which are primarily managed by administrative 
and departmental information systems. 

- The second part describes the nature and structure of image information (the image kernel model). This part of 
the model had to be defined in order to allow a common understanding of the images to be shared by all the 
various systems exchanging medical images, for example acquisition systems and workstations. 

- The third part describes at a conceptual level the entities which are involved in the image flow management 
process itself (the image management model). It allows the MIMOSA system to support communication 
mechanisms and to guarantee an adequate level of availability of the images to the users. 

The functional model describes two classes of functions: 

- The first type of function is user-oriented and is related to exchanges with external entities related to end-users. 
These functions have to manage user data and user dialogues. They indicate the relationships of the interface of 
the MIMOSA model to the user world / user applications. 

- The second type of function is oriented towards data circulation, transfer and management. Therefore, the 
functional model is centred about the concept of Data Availability Management. Most of these functions are 
internal and they have to deal with scheduling information and the image management model. They possibly 
exchange information with external entities dedicated to system administration (e.g. right access management, 
data administration), to archiving or storage, and to interoperation with administration systems. 

The dynamic model organises all the functions occurring in the functional model into an operational whole. This 
model focuses on the synchronisation of procedures. The dynamic model takes real life usage into account, where 
abnormal, exceptional or illegal events can occur, and defines what to do in these situations. It is also concerned with 
the availability of all necessary data. 

Most of the concepts described in the data model are widely addressed in either other work on medical information 
management, especially in other EC projects, or by standards such as MEDICOM or DICOM. However, the MIMOSA 
viewpoint differs because it is intended to analyse this information in terms of image handling, archiving and 
communication considered together and not in terms of just patient record handling or of just image communication. 
Moreover, some concepts which are necessary to be addressed when the image management is considered, do not exist 
elsewhere. For example: 

- The concept of image collection (or "Generic View") is a structured association of various image related objects 
(e.g. views on patient record emulating the various jackets found in an actual patient record, panel views, image 
related notes, image processing results, reference image base). This original feature of the MIMOSA model has 
resulted in a proposal from the MIMOSA team to CEN for offering a standardised mechanism of image related 
object grouping. 

- The mechanism of opinion / advice requests for opinion / advice has been developed from users' requirements. 
This exchange mechanism, found in daily routine and involving mainly images, is currently not addressed by the 
DICOM standard. 

- The concept of Data Availability in terms of user's constraints has been introduced. This concept is proposed for 
managing prefetching, preloading and layered archives in a generic, deterministic and implementation- 
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independent way. Existence of such a description is crucial to guarantee the flexibility and the evolution of the 
PACS with regard to the hardware and software implementation. 
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A set of clinical case scenarios introduced in order to assess the MIMOSA model clinically, to facilitate its 
comprehension and to test its relevance with respect to today medical practice. The use of these clinical cases allowed 
for the correction of some drawbacks of the early versions of the model and thus contributed to ensuring the validity of 
the model. As this form of validation has its limitations, additional methods for validating the model, in particular 
prototyping, were applied. 



6.3. Relation with standards 



The user- view was the major influence during the stage of defining the model. The definition of the architecture has 
introduced another view onto the MIMOSA system, which is complementary to the previous one. 

As a MIMOSA system interacts with external applications (such as image sources, reporting workstations, HIS / DIS 
or archiving systems) provided by different vendors and implemented on different hardware platforms, such a system 
must be implemented using a well defined architecture, taking into account existing standards. 

The standards related work was particularly focused on that part of the model involved in the MIMOSA demonstrator. 
It resulted in: 

- A general survey of image formats applicable. This survey showed that, at the moment, one can not rely on a 
single format, and that a more appropriate strategy consists in allowing several representation formats to be used. 
An in-depth analysis of the DICOM / MEDICOM standard. This indicates that DICOM can be used to implement 
most of the interactions between the external applications and the sub-systems providing the MIMOSA services. 
However, the comparison between the MIMOSA and DICOM data models showed a number of inadequacies, 
which would require the definition of new Information Objects (for example, for Clinical Requests, Views on 
Patient Record). In a similar way, it appeared that in same cases, the utilisation of DICOM service classes to 
request or deliver MIMOSA services was not fully consistent with the original semantics of the DICOM Service 
Classes (e.g. Delete images). In both cases, the problems and limitations encountered will be forwarded to the 
standardisation bodies in charge of DICOM / MEDICOM update and evolution (CEN TC 251 / WG4 and ACR- 
NEMA WG 6). 

- A proposed implementation architecture based on client / server paradigm. This architecture was used with 
success in the framework of the MIMOSA implementation. 

- Feedback provided to the modelling group. The analysis of the constraints involved in the choice of an 
architecture required specifying in greater detail the data and dynamic models, leading to refinements and 
modifications of these models. However, these modifications did not affect basic assumptions of the project. 



6.4. Prototyping 

In order to test and demonstrate the importance of the MIMOSA modelling approach, concrete experiences are of 
primary interest. A teleradiology-focused prototype has been developed in co-operation with the 
EuriPACS / IMPHONE topic and is implemented between Luxembourg and Pisa, Italy, using an Internet Link. 
Concurrently, a PACS prototype implementing the MIMOSA Data Availability mechanisms and the Examination 
Context concepts was implemented at the Rennes University Hospital. 

This implementation phase proved that MIMOSA concepts were adequately introduced and properly modelled. During 
the preliminary phase of system definition, the major concern was to map the users' way of thinking and the site 
specific requirements with MIMOSA Data and Functional concepts. In particular, the MIMOSA Clinical Request and 
Examination Step concepts were proved to be generic enough to cope with the local organisation of radiological acts, 
and complete enough to carry all examination related data currently manipulated during acquisition and interpretation 
processes. Data routing and preloading mechanisms were easily translated in terms of the MIMOSA Data Availability 
Management features. All associated concepts such as MIMOSA Directories, Platforms, and Transport Requests were 
found to be a very valuable foundation for the specification and implementation of flexible, evolutionary and effective 
Data Flow Management components. 

The implementation has also validated the functional model and led to a refinement of the model. The MIMOSA 
functional concepts of Acquisition and Reporting Preparation fully addressed the specific site requirements in terms of 
workflow, and have made possible the implementation of consistent Study Status tracking mechanisms. In particular 
they were fully compatible with the need for distributed worklists, allowing for the clinical user to be informed on a 
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real time basis of work to be done on acquisition or reporting workstations, to be informed of associated examination 
status (scheduled, complete, cancelled, ...) and to have direct access to examination relevant data. In the MIMOSA 
functional model, data migration is driven by events associated with exam steps (scheduling and completing events), 
and generated following specific configuration rules. This approach was a very valuable basis for the specification of 
efficient mechanisms for moving data, specifically adapted to the needs of the site. 

During the MIMOSA prototype specification, particular attention was paid to the data import / export mechanisms. 
This was the opportunity for improving the MIMOSA functional and dynamic models with respect to these particular 
aspects. 

The architecture of the demonstrator was defined as far as possible, in accordance with existing standards. The 
mapping between MIMOSA concepts, functions and services and those of DICOM was investigated, and a DICOM 
compatible form was used when possible. 

The current teleradiology prototype between Luxembourg and Pisa allows advice requests to be exchanged between 
radiologists. The results of the demonstrator will be exploited by clinical sites in the SAAR-LOR-LUX European 
region for teleradiology purposes and, more specifically in the context of agreements between those hospitals. It is 
planned to develop a set of teleradiology services and to extend the range of users to clinicians and general 
practitioners. 

The 1994 PACS prototype at Rennes was focused on functional requirements and on the data that are manipulated 
during exam acquisition and interpretation processes. It did not address the security, reliability and administration 
issues that are inherent in a complete Image Management System. The implementation of a complete and secure 
system is outside the scope of the MIMOSA topic. The prototype implements basic administration and configuration 
tools. 

After a first phase of experimental work and ad hoc improvements of the preliminary prototype at the Rennes Hospital, 
the next objective, during 1995, is to transform the prototype into a MIMOSA clinical demonstrator that will be used 
by Health Care Professionals in clinical routine conditions. This demonstrator will include DICOM communication 
components and will be completed with administration and security / reliability mechanisms. By continuing the 
evaluation beyond the scope of the EuriPACS project itself, it is intended to illustrate how valuable the MIMOSA 
approach is to achieve an integrated solution in real clinical environments. 



6.5. Highlights 

As stated before, the ultimate objective of the EurIP ACS-MIMOSA topic is to build a generic framework for a system 
capable of handling a wide variety of biomedical images, using a suitable architecture and providing the basic services 
expected from end-users of Medical Image Management Systems. We consider that the MIMOSA consortium has 
achieved this objective. 

The implementation of the various demonstrators has shown that the MIMOSA approach is compatible with the open 
system philosophy, and with the use of industrial and official standards as the demonstrators were implemented on 
multi-vendor workstations and environments (e.g. Sun, HP). The involvement of industrial partners in this 
implementation (i.e. GEMS which belongs to the MIMOSA team, and HP, IMPHONE partner, at Pisa) is essential 
with respect to the industrial spin-off of the project, which is the development of efficient and cost-effective multi- 
vendor PACS systems. 

The possibility of customisation is an important feature for the acceptance of PACS, and it must be possible to 
implement a variety of different sizes of system, from very small department-based systems linking perhaps only one 
or two image modalities, to large-scale systems extending throughout the hospital, to systems extending between 
different types of health care organisations, for example both hospital and community-based. Therefore, as MIMOSA 
integrates the various facets of handling images, documents and information related to images, rather than being 
limited to the PACS architecture itself, MIMOSA contributes toward the objective of being able to implement a 
scaleable PACS. 

The results available from the current implementations have validated main concepts and now demonstrate the interest 
of the MIMOSA approach. However, MIMOSA has not been designed to interconnect with any specific HIS whilst 
having potentially a substantial intersection with projects dealing with the general patient record and clinical act 
management. The future of the MIMOSA project could well be directed towards the complete integration of the 
patient record and image management. 

However, the MIMOSA model can already be used as a basis for developping a large scale PACS, as for example, the 
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MIRIAM project of the Assistance Publique - Hopitaux de Paris (AP-HP) . AP-HP groups together 50 hospitals in Ile- 
de-France, France, comprising 800 services, has 32 000 beds, and employs 80 000 persons. The "Direction de 
l'Equipement et du Systeme d'Information" of the AP-HP already foresees in its MIRIAM project that it needs "to 
define the impact of the MIMOSA model within the information system of the AP-HP, and to investigate the 
adaptation which will be necessary for the numerous internal hospital organisations of the various hospitals of the 
group" (translated by the authors of the present MIMOSA report). 
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